09 5 / 2012

Having dreamt up the perfect App, you’ve implemented it, and after throrough beta testing it has a user experience as slick as its interface is beautiful. Now it is live in the App Store and noone is buying it. Why not? Most likely because you haven’t told them it exists yet. This is a guide to shouting very loudly about a product without spending any money. It is hard for a developer to swap the familiar engineering hat for a marketing hat, but as a recent Ars article made clear, the ability to make that switch is what separates employees from employers.

My first marketing recommendation is tireless footwork. If you want people to know about your app, tell them about it. Email them, tweet them, facebook them, do whatever it takes. There is a fine line between genius marketing and reputation damaging spam, but for the most part morals are a luxury of the rich, so stop thinking and send that email. A Daring fireball post was the first big break for our markdown editor Valletta, we shipped an extra $2000 dollars worth of software the next day, and all we had to do is ask.

So what should you put in these emails? When writing promotional materials, remember that noone has a reason to read your brochure/landing page/press release, so it is your task to engage them. If readers don’t like the title, they won’t read the first sentence, and if the first sentence doesn’t capture the imagination then the killer feature described at the end of the first paragraph will remain a secret. Forget the programmer’s maxim of never repeating yourself; communicate your key feature in the title, then again in the first sentence, expand on it in the first paragraph, and ensure it is immediately visible in any videos or screenshots you distribute.

In the case of web pages the title -> sentence -> paragraph sequence of reading doesn’t apply. People read out of order, usually biggest and brightest first. On our Valletta publicity page we chose the “single pane markdown editor” and “configure with CSS” messages to promote, making them immediately visible with further details written below. The screenshot and video are crafted to ram that message home once more, in all cases we design our marketing collateral so that the first thing you read is the first thing we want you to know.

Whilst I’ve always been suspicious of any political system that requires Permanent Revolution, this communist ideal is well applied to software. In the age of the App Store it takes no more than a minute to transmit an update to millions of users, so why not split your development into weekly updates? The benefit goes beyond the enhanced quality of your software; users notice the improvements and your application becomes a living, evolving entity to them. From a user’s perspective if the software isn’t fixed in stone, then neither are its flaws, and they become temporary inconveniences to be worked around, rather than festering wounds that annihilate your reputation. The weekly update strategy propelled Pocket God through the App Store’s million download barrier, and Google Chrome’s six weekly updates are such an important part of its success that Mozilla have copied it with Firefox. If it isn’t absolutely clear what place an excited and engaged userbase has in your marketing strategy, then remember that nothing you say about your product will ever be as valuable as what your users say about it.

Despite what I said about swapping from programming mode to marketing mode during at least part of your week, don’t discard your hacker’s mindset completely when you do so. The electronic and print media is a system, and a skilled marketer is someone who can control that system as adeptly as a hacker can manipulate a computer. Attack your marketing activities with the same creativity and zeal you would a coding problem, and not only will you succeed, you may even enjoy it.

03 5 / 2012

Texpad 1.3.1 made it to the Mac App Store a few days ago. In it we added support for typesetting makeindex/bibtex simultaneously, we added support for biber and we fixed a couple of bugs introduced in the 1.3 rewrite including the shell escape flag.

Meahwhile we have finished Texpad 1.4, the highlights of which are editor themes, custom build scripts(more on these to come) and global search. Also, we fixed a remaining bibtex problem, sped up the parsing and plugged a memory leak. 1.4 has just been submitted to the App Store and it should be available 7-10 days from now.

21 4 / 2012

We submitted Texpad 1.3.1 to the App Store yesterday morning. This fixes shell escape which we broke during the 1.3 rewrite. It should be available in the App Store around this time next week.

New functionality in Texpad 1.3.1

  • Supports the Biber engine as well as the Bibtex engine
  • Many fixes to the makeindex typeset chain, including an option for typesetting with both makeindex and bibtex.
  • Improved support for VoiceOver

The next update will be Texpad 1.4, and it will have global search to allow you to find and replace across your entire LaTeX document including the the included ones.

17 4 / 2012

Our most substantial update to Texpad yet, 1.3, is now available as a free update in the App Store. We started on the rewrite as an internal refactoring to prepare Texpad for future development, but along the way we have fixed many outstanding issues and we have overhauled the user interface. We are most proud of the spinning cog when you typeset, but a more complete list of Texpad 1.3’s upgrades are.

  • Rewrite of typesetting engine to fix a variety of Bibtex issues.
  • Integration of kpathsea with Texpad’s file include mechanism. Texpad will automatically open and edit common files stored in texmf directories.
  • UI enhancements
    • matching parentheses are now highlighted
    • welcome screen
    • new icon
  • Integration with OS X’s document system. Lion users now have access to Versions, and Papers user have Magic Manuscripts support.
  • pLaTeX support
  • You can add or edit templates (“File | Add/Edit templates…”)

Anyhow, we hope you like the new Texpad as much as we do, and if there are any issues we and and our beta testers (a million thanks to all of you) have missed, please let us know.

12 4 / 2012

We recently blogged about Valletta Ventures’ woes surrounding Apple’s sandboxing policies. Discussions among ourselves and the feedback we’ve received have led me to wonder how users would really react to the inevitable situation where their precious Macs suddenly become useless for tasks the owners paid a tidy sum for. As much as we are all willing to pay a premium for the Apple branded personal computers, we only do so because they allow us to do useful things as well as consume the entertainment content, a big chunk of it usually bought from iTunes and iBookstore. We shell out the extra bucks for a better user experience while knowing that the machine is not a lesser one compared to a PC. Indeed, a plethora of innovative apps makes it a superior one.

From OS X Mountain Lion onwards, users will be able to switch on code-signing. I have no gripe with that as it make the Mac more secure for an average user. In addition, on Mountain Lion, code-signing will be configurable and won’t render my unsigned apps unusable. What worries me is the trend and whether or not, a few versions down the road, we are to face a possibility that unsigned and eventually unsandboxed apps are not allowed to run by the operating system. So if your favourite app hasn’t yet been converted to conform with sandboxing (or isn’t going to be converted since the price may be throwing away features that make it the app you find so useful), your options are rather limited:

(a) you either stay on the last version the app happily runs on and don’t upgrade to the latest and very tempting version that Apple have just pushed out. This way you continue using your favourite noncompliant apps. You learn to live without the new UI innovations of the more recent versions you’re missing out on, until you have to upgrade the hardware, at which point you say goodbye to Apple.

(b) or you do what the rogue pioneers have been telling me to do with my iPhone for years: jailbreak! I haven’t yet been tempted as I use my phone to do Apple-sanctioned things only and leave all else to my trusty Mac. But if users are unable to use their Macs for things like apps that compile LaTeX documents, they’re likely to be forced to consider options such as jailbreaking, even if it means all apps have to be manually updated, rendering their Macs no better than Linux boxes whose distributions have to be painstakingly maintained. This option of course would be a workable solution if their were a market place and an ecosystem for jailbroken apps.

Well, the third option that you stop doing anything useful with your Mac, only using it to browse the net, consume media content and read books, while shelling out for (dare I say) a Windows 8 PC for your actual work may not be a very economical one.

If the future of OS X is a tightly controlled and an effectively closed platform that constricts a user’s workflow, the beautiful UI may have to be parted with, albeit with heavy hearts. Jailbreaking may allow you to run certain apps that you were missing on the shackled , sandboxed system, but you’re on borrowed time. Apple will continue, as is their wont, to make it harder for the jailbreak community to thrive or exist. Among other things, your warranty and Apple Care will most likely to be invalidated in a way similar to the jailbroken iOS devices. As a long term Mac user and developer of Mac apps, I certainly hope this scenario can be averted and a better, more flexible implementation of sandboxing can be found which lets people continue to use their Macs for business as well as pleasure.

10 4 / 2012

Recently I wrote about the problems Texpad is likely to encounter in the App Store after the 1st June. This has prompted concern that we are planning to drop Texpad entirely and move onto other projects. Having just spent 6 weeks rewriting Texpad almost from scratch for the v1.3 update, I can assure you we don’t intend to forget about it.

Unless Apple change their Sandbox policy, it is unlikely that we will be able to continue distributing Texpad through the app store beyond 2012. However, anyone who has bought Texpad App Store will receive free updates if we are forced to distribute through our webstore.

Texpad 1.3, which should be available in the App Store any day now, is a substantial rewrite, but most of the changes are internal refactoring, the intention being to sort some persistent issues and tidy up the codebase ready for the next phase of development. 1.3 fixes many BibTeX and typesetting issues, adds support for Lion Versions and autosave, adds support for Paper’s magic manuscripts, and there has been a reworking of the user interface.

The aspects we intend to concentrate on in the 1.3.x series of updates are global search and autocompletion. With 1.3’s better LaTeX backend we are in a position to autofill tags such as \bibliographystyle and \documentclass by looking for .cls and .bst files in the latex search paths.

Our big plan for Texpad however is to cover more of an academic’s workflow. When writing a paper one is constantly referring back to other papers, wouldn’t it be great if that happened in the right hand pane of Texpad? The first step will be improving BibTeX parsing and adding a bibdesk-style editor for .bib files. Once Texpad knows what papers you are interested in, it can give you the option to view those papers (downloading them if they aren’t already installed). Eventually by just entering an arXiv number and a citekey Texpad can download the paper, display it for you, and add an entry to your central bibtex file.

In the meantime Texpad 1.3 has been stuck in the App Store review process for longer than usual, but it should be with you any day now. I hope you like it.

04 4 / 2012

EDIT: We’re not abandoning Texpad! It seems that some customers are under the impression that we don’t intend to work on or sell Texpad beyond June this year. Let me assure you that that’s not the case. Having invested a lot of time in revamping it recently, we have firm plans to continue selling it through our own web store in the event that Apple remove Texpad from the App Store in 2013. Existing users will also be provided with a way to download future updates directly from our website.

Six months ago we released Texpad, an OS X LaTeX editor into the App Store, and we have been developing it ever since. We have had great fun reinventing the LaTeX front end and smoothing over LaTeX’s wrinkles for users, but our job is unfinished and unless Apple reverse their sandboxing policy, our adventure will soon end. In fact it will be the end of the road for any products interacting with the LaTeX typesetting system.

The Sandbox is a permissions system for OS X inherited from iOS. It reduces the damage any one application can do to your system, but it does so by limiting the access of that application to the filesystem. In cases such as Texpad those shackles prevent the application from doing its job. As of 1st June the Mac App Store will not accept new applications or updates to existing applications that are incompatible with the Sandbox, and it is not unreasonable to assume that noncompliant applications will eventually be dropped completely. Certainly there is no way to adapt Texpad to comply with the Sandbox, but more worryingly it is unlikely any LaTeX editor could ever operate satisfactorily from within the Sandbox.  LaTeX is ubiquitous in the academic world for document creation, and Apple will lose a lot of customers like this. Far more of concern is the drift of OS X towards the locked down model of iOS.

I saw the iPad era rebranding of iPhoneOS to iOS as tying up typographical loose ends, but I missed the point. When Apple introduced the iPhone it was a very cool touchscreen iPod that could make phone calls, and iPhoneOS was a piece of software to make it happen, but by the iPad’s release, the focus was on iOS, the touchscreen platform complete with a record shop, a video rental store, an enormous software development community and a version of Angry Birds for every day of the year. Apple’s gatekeeping of iOS, although dictatorial and often unjust, contributed to iOS’s rapid rise by mandating a basic level of competence and security for all software. As the fart apps showed it didn’t guarantee quality, but users showed their appreciation for this effort with the insatiable thirst for shiny touchscreen devices that made Apple the world’s largest technology company.

It is a sound plan for Apple to replicate the successes of iOS in their desktop offering. The Mac App store with its rigorous review process was the first step, and Sandboxing is the second. For anyone who doesn’t know, sandboxing restricts the application’s file system access to either an operating system assigned “Container” directory or files that the user has added to the Sandbox by use of the operating system’s open and save dialogs. This is great for applications which require no access beyond what the Sandbox allows, because it guards against programmer incompetence or maliciousness by fencing the application off from files it does not need to access. However consider an IDE, most of which store their project file in a directory amongst source files. When the user drops the project file on the icon the app gets access to the project file, but not the source files, which are outside the Sandbox. The Apple approved approach to this problem is to store the files in a package - a specially named directory that is displayed as a file by the Finder, but hiding away source source files would be unacceptable to developers.

Our particular worry with Texpad is that we have designed the editor around the concept of the user dropping just the root LaTeX file onto the application. Texpad will parse the file, automatically open included files, and present them all to the user in a unified editor. For example, many users store a central bibliography file (e.g. central.bib) in ~/Library/texmf/bibtex/tex. in Texpad simply typing \bibliography{central} will stimulate Texpad to dig it up and load it for you. This behaviour is ruled out by the Sandbox because the user has only granted permission for Texpad to open the root file itself. We would never do it, but we could avoid this limitation by wrecking the user experience, forcing the user to open the files one by one. Unsolvable however is the problem of LaTeX itself, which can never be compatible with the Sandbox.

The moment you boot LaTeX it sets about tripling the number of files in your root document’s directory. These are the .aux, .log, .toc, etc files used by the many parts of LaTeX to talk to each other. At the risk of repeating myself the user hasn’t given Texpad permissions for these files, and as LaTeX inherits Texpad’s permissions it fails. Even in the unlikely case that this problem were overcome, the sprawling and unruly nature of the LaTeX build process almost guarantees that at some point a script will fall foul of the sandboxing code. If sandboxing continues as planned then on June 1st Texpad and all other products in the App Store interacting with LaTeX will no longer be able to submit updates (although Apple has made a nebulous promise that it will allow bug fixes). As recent graduate students, we have witnessed Macs become ubiquitous within the academic world in the past decade and we estimate that there are around 50 million academic LaTeX/OSX users worldwide, not counting the engineering companies, non-academic research organisations and publishing houses who use LaTeX. As big as the App Store is becoming, it is still relatively small and there is a little bit too much income there for Apple to turn there back on.

Not long ago there was no App Store, and all Mac developers handled payment, installation and updates by themselves. Unfortunately it is not hyperbole to describe the Mac App Store as revolutionary, and consumers have very quickly become used to its convenience and security. Shopping for software such as this outside the store is no longer the norm, and it is unrealistic to expect the same income outside of the App Store.

It is even more unrealistic to expect Apple’s moves to lock down OSX and guarantee their 30% App Store cut to cease on June 1st. Mountain Lion, the next iteration of OS X (10.8), will warn users when they execute any code not signed by an Apple approved developer, and although I am departing from definite fact when I say this, I am certain that at some point OS X will only run App Store approved software. There is no point building a webstore now to see it shut down a year later by a fully locked down OS X 10.9. Therefore it seems to me that June 1st will be the end of the line for Texpad and other “non-compliant” software.

The dedication to Macs we mentioned above goes well beyond academic LaTeX users, fanbois or even the consumer market that Sandboxing is so squarely aimed at. A recent HN poll showed that the mix of excellent user experience, solid technical underpinnings and flexibility has made OS X the platform of choice for hackers and entrepreneurs. Would this love affair continue if it becomes impossible to experiment with the operating system beyond what has been preapproved by the censors in the Mac App Store? I doubt it, and I also doubt that OS X will retain its market leading status when that community packs its bags and heads off into the welcoming arms of Mark Shuttleworth and Ubuntu.

Sandboxing won’t hurt the average consumer, and despite Apple’s 30% cut of all sales through their store it won’t even harm developers of a lot of consumer software, but for those of us who do more with our laptops than browse the web, watch TV, and edit Word documents it means the end of the line with Apple as a platform.

What can we do? Protest! If you are a developer with a potentially noncompliant application don’t stay silent and hope Apple postpones its sandboxing deadline again, send them an email and explain exactly why their Sandbox will kill your software. If you are a user of LaTeX or other software that is unlikely to make it into the Sandboxed era let Apple know that you consider your computer your property to use and abuse as you wish; let them know it is more than a thin client for iTunes and the Mac App Store.

28 3 / 2012

A while back I wrote about the unfortunate state of the LaTeX codebase, and how it scuppered our project to port it to the iPad. We took we learned during this project and built a desktop LaTeX editor, Texpad. Maintaining and updating Texpad over the past six months has given us insight into the workings of the TeX system, the problems it faces, and its potential saviour - XeLaTeX.

Currently we support five typesetting toolchains in Texpad, pdfLaTeX, LaTeX -> dviPDF, XeLaTeX, LaTeX -> dvips -> ps2pdf, pLaTeX->dvipdfmx. The obvious question is why? why do we need five toolchains performing exactly the same task? This is easiest explained with the problem of embedding image files. pdfLaTeX can directly include standard image formats such as JPEG and PNG, but it needs an eps2pdf converter to directly embed EPS content. LaTeX on the other hand includes eps but not JPEGs or PNGs. Not to worry, there are add on packages to convert JPEG or PNG to eps so that LaTeX can use them, and likewise there is an EPS to PDF conversion tool for pdfLaTeX. In this typical example of LaTeX’s fragmentation there are two typesetters and two associated packages in the place of one single working typesetter.

That explains the need for pdfLaTeX and LaTeX->dviPDF, but why do we also support LaTeX -> dvips -> ps2pdf? One reason is the pstricks package. This package will only work when there is a PostScript intermediate in the typesetting chain, for example the LaTeX -> dvips -> ps2pdf chain. However, most people don’t want an unnecessarily slow 3 step process, so we support the single stage pdfLaTeX as well. On top of that there is XeLaTeX for unicode fonts, and pLaTeX for an alternative approach to multibyte characters often used in Japan. Instead of supporting one typesetting chain, we have had to support five and our efforts have been split. Unforunately, so are the efforts of everyone else putting time and money into LaTeX.

This fragmentation of code and development effort has recently spread beyond the core typesetting tools. Biber, the replacement for bibtex in the biblatex chain, is a great improvement over the venerable bibtex, but now there are two biblatex options, both actively developed, but only one of which is necessary. For all its advantages, Biber has further fragmented the LaTeX project.

Another effect of this fragmentation is bloat, which is very straightforward to measure. TexLive 2007 takes up 1.37 GB on my hard drive, TexLive 2008 requires 1.76GB of space, but by TexLive 2011 the installation has grown to a stunning 3.01GB. This is more a symptom than it is a concern in itself, but an increase 1.6GB in four years isn’t moderate bitcreep, it is a sign of morbidity and it is unsustainable.

The true problem with this fragmentation is that the effort put into LaTeX and its ecosystem has been split. For example, the effort we have put into supporting the four surplus toolchains could equally have gone into better autocomplete, or a pstricks GUI. The effort we will put into supporting Biber could go into a tikz GUI now that pstricks has been replaced. More importantly if the community’s endeavours hadn’t been split between all five typesetting chains, they could have been spent upgrading one typesetting chain to handle all contingencies and making that one tool truly great.

Those are my complaints, so what is my solution? Texlive 2013 (2012 is frozen at the end of this month) should have just one typesetting tool - XeTeX. XeTeX outputs directly to pdf in one step, it is by far the easiest tool to support for external products, its usage of unicode and integration with modern fonts would allow the ancient texmf to be dropped entirely, and with a little bit of development platex (japanese character support), could become unnecessary. With just one underlying typesetter to focus on, development of that typesetter would accelerate greatly and many packages would become obsolete, further freeing up time for purposeful TeX development.

A second phase to this reorganisation would be to carry out the same trick with the packages. Where there is duplication (e.g. pstricks and tikz, or bibtex and biber) make a choice and keep one. Once again, the time freed up by culling packages would more than compensate for the time required to fix up the knockon effects throughout the TeX system.

Undoubtably a change this severe will be painful for some, but it will be less less painful than heading out to the computer shop in 3 years time to purchase the 2TB harddrive that will be required for the exponentially expanding tex updates. For those for whom adding the letters xe before typesetting is too much to bear, or for typesetting ancient documents, it is straightforward to use two LaTeX distributions side by side in the interim (you would simply have both 2012 and a 2013 folders in /usr/local/). I will happily build a tool to rewrite the /usr/texbin symlinks to allow for easy switching if that is what is required to make this happen.

02 3 / 2012

We believe that two pane markdown editors waste your precious screenspace, so our OS X Markdown Editor Valletta is designed around a unique Combined View that displays only the line under the cursor as Markdown source, and the rest in “marked-down” form.

Valletta 1.0

In addition to this Valletta is fully configurable via CSS so that the edited text appears exactly as it will on the website, it lets you export to Word and PDF files, and it specifically optimised for Lion’s fullscreen mode to give you a beautiful and distraction free writing environment.

Get it now in the App-Store

02 3 / 2012

Valletta Ventures’ markdown editor released

Valletta Ventures’ markdown editor released