Some thoughts on why Pythonista is 2-3x more popular than Editorial
In addition to what @ccc and @jonmoore said, Pythonista is actually more successful commercially than Editorial (currently about 2x-3x). Of course, part of that may be due to Editorial not being optimized for iOS 7 yet etc., but I still think Pythonista can appeal to a lot of people with a Python background that I couldn't easily reach with Editorial. While there's a lot of shared functionality, the focus of the apps is just very different, and I'd guess that a lot of folks find Pythonista just by searching for "Python" in the App Store.
I'd say the reason that Pythonista is far more popular than Editorial is quite simple from a marketing perspective, Pythonista has a clear & defined audience whereas the audience for Editorial is nebulous and undefined by it's very nature. You only have to look at Brett Terpstra's database of text editors to see how cluttered the playing field is. The audience for Editorial is restricted to those who are already comfortable with the like of Automator/Alfred/Applescript etc, which outside of our nerdy little world is a tiny percentage of OS X users, nevermind IOS users, the good majority of which wouldn't know what a line of code looks like let alone have the ability (or more importantly - need) to write code.
I think it would be smart to ship the next update of Editorial with a bunch the best workflows that the community have thus far created so as to soft sell the benefits of creating workflows. When the likes of Katie Floyd of Mac Power Users freely admits she can't get her head around the benefits of Editorial it's saying something.
I'm not saying that the next version should change focus, I love it just the way it is; and the glimpses of the future you've shown us look very promising indeed. However at a fundamental level Editorial is still a writing tool, not a programming tool so I feel you need to somehow 'prove' the benefits of automation workflows (through the aforementioned pre-installed workflows) to new users otherwise they're going to wonder what all the fuss is about. Just because you include marvelously written documentation built into the app explaining both the benefits and how to create workflows doesn't mean that new customers will explore that documentation if they don't get the benefits in the first place.
In reality Pythonista has a massive audience of programmers and the likes of Byword/1Writer/Phraseology etc have a massive audience of bloggers and now that IOS7 handles inter app rich text formatting, the biggest audience of all - general writers, are well served by non Markdown based word processing apps such as IOS Word (Office 365) and Pages. Editorial has huge benefits over any other Markdown based text editor available on IOS, it's just that the audience of people willing to write/install individual workflows that provide all that extra firepower is unfortunately limited. The other thing that new users of Editorial don't understand, is the lack of system wide utility functions such as 'open in', pasteboard functionality and suchlike. The workflow system obviously allows you to 'roll your own' system utility functions specific to your own needs but new users don't understand that.
On the surface of things you'd expect Editorial with it's Automator like workflow approach to scripting to have a greater potential customer base than Pythonista but once you analyse audience attitudes and needs I'd surmise that the opposite is true.
None of what I've written here is intended as criticism. Editorial is the most used application on any of my IOS devices and further than that I'd love to see a version on OS X! I just feel that more work is needed for it to cross over into the wider audience (and sales) it so richly deserves.
I agree with the "bunch of best workflows" idea but think it might have copyright issues.
I agree with the "bunch of best workflows" idea but think it might have copyright issues.
I obviously wouldn't include user-made workflows without asking the authors, but another problem with a lot of the best workflows is that they often assume a particular setup, e.g. usage of a certain web service (Evernote, Wordpress...), or they only make sense for a very specific kind of writing...
I've tried to make the ~10 bundled workflows as generally-useful as possible, and I don't want to include anything that would require some sort of manual setup (e.g. changing API keys...).
I'm open to suggestions for other workflows to include though, either existing community workflows or even just ideas (if it's possible to build them with Editorial's workflow system).
I'm not surprised Pythonista is selling better. Those who want to tinker in Python are more likely to do it in a more general-purpose app. Editorial is aimed at text/document manipulation, and most people who write don't even do it in Markdown, so it's naturally difficult for a plaintext writing app to dominate the "writing app" space.
@MartinPacker - Arguably, any workflow in the workflow directory could be included by default. I just don't know that it's necessary, given that users can just search there directly. Perhaps a better in-app method of accessing the workflow directory would help, though.
In a different thread, @MartinPacker wondered why I would continue Pythonista at all, "now that Editorial is well established". I said that Pythonista is more successful commercially, but I didn't mean that I'm unhappy with Editorial's sales at all.
Perhaps a better in-app method of accessing the workflow directory would help, though.
I agree. The workflow directory will be more integrated in 1.1, though I'm always a bit worried about Apple's review guidelines. The workflow directory is already in kind of a gray area, since it's officially not allowed to download executable code at all...
In my case, I found Editorial because I found Pythonista, and then followed the “other apps” link.
Then I think we have a deal. :-) @omz is working on better access to workflows.
I found Pythonista long before Editorial. I think it was probably Brett Terpstra or Federico Viticci who made me aware of Editorial.
i'd add some example UI Examples like the calculator (shown in your post of the ui module) or somethong cool
Just out of curiosity, but what prompted this post?
I just wanted to stimulate some conversation that might be helpful to Ole as he prepares for the public launch of 1.1.
I think the integration of TaskPaper functionality will widen the audience but there's some really great workflows that help show how Editorial can shine scattered around in different places not just in the 'official' repository.
As a starter for 10, here's a bunch that I think are worthy of inclusion. Some of them may already be in the bundle that come with Editorial on first install (it's a long time ago for me!) so be gentle. Also I've renamed a lot of stuff so they may not match those exactly from the official repository.
Here goes (and these are those that don't rely on x-callback with 3rd party apps):
- Search Google/Wiki via internal browser
- Global Search
- Create Markdown Link (from internal browser. The Federico Viticci version is the best I've come across as it allows you to choose between inline & reference links)
- Create Markdown Link (from clipboard, one of mine based on the above but obviously doesn't grab the page title too as the clipboard only has a single item of data)
- Create Markdown Image link
- Convert Markdown Links (uploaded three of these at the weekend)
- Create unordered list (useful if you've grabbed a list from somewhere else without MD formatting)
- Create numbered list (as above)
- Paste As - Block Quote, Code Block, Paragraph
- Wrap selection (double quotes, HTML blockquote et)
- Create footnote
- List URL's
Most of my text tool actions use the third party TextTool app but Editorial has a bunch of useful stuff in it's actions catalogue that could be bundled as a 'select from list' (added benefit that you can easily chain stuff together this way)
These are self explanatory but worth mentioning that many people don't realise how useful the Copy Bookmark URL action is for creating wiki style links to other docs in your library.
I constantly make use of the 'evaluate math inline' action and I think it's probably a good idea to include a some 'open in' type stuff for the bundled Apple apps that have a URL scheme like the reminders app (seeing as editorial doesn't provide 'open in' as standard).
I'm not suggesting for a second that all of these should be included but these are some of these workflows are essential to me on a daily basis.
I'm a musician as well as being a UX consultant and I make use of apps like Native Instruments 'Reaktor' & Cycling 74's 'Max/MSP' (effectively visual programming environments for the creation of musical applications/instruments). With both of these apps the majority of my learning came about by deconstructing the stuff that came bundled in the library. Editorial is a very different beast but theuser learning path is very similar.
There are some parts of Editorial I like more than pythonista, but Editorial isn't a true superset of the Pythonista features. For example, for some reason when running certain python scripts editorial seems to crash more often. For me, usually at a console input (raw_input). The editor.get_file_contents method would be real nice in pythonista, but that might cause some TOS issues with Apple.
seems to crash more often. For me, usually at a console input (rawinput).
Is this (more or less) reproducible for you? If so, could you show me a script that causes this crash? I've seen a lot of crash reports coming in that seem to be related to
raw_input, but I haven't quite figured out what's causing this.
Nevermind, I think I just found a pretty likely explanation for this sort of crash...
I circumvented the issue by replacing all raw_inputs with a console.input_alerts. As I incrementally replaces the raw_input function the crashing occurred occasionally at the remaining raw_input functions. Sometimes the first instance of hitting the input, and sometimes a subsequent instance.
It is a random generator script that loads a file of random generators (on dropbox) and asks which random generator to run. It generates story prompts, random locations, items, names etc. If you want I can include it but it is over 300 lines long, so not the shortest thing to include on a forum.