Attila's Den

Here’s a small compilation of the things that end up driving me completely nuts when I’m working with a designer on an app. I guess all those are pretty common. They’re not a deal breaker but I find it exhausting to have to go through it over and over again… And generally end up pissed off at some point. So here we go. My top recommendations for not driving your developer completely crazy:

• Know UIKit. Read Apple’s doc, use apps, read a dev book for beginners
• Read the fucking HIG
• Deliver vector graphics only (SVG is a great format, compatible everywhere… Wait Photoshop doesn’t export that? That’s because that bloated turd one calls a software is not doing vectors. Ditch it and work with real tools)
• Don’t use shitty fonts. Thin fonts should be banned forever in the HIG
• Designing an app and a web page are completely different tasks. Go back to points 1 & 2
• crop your pictures correctly
• use transparent backgrounds
• group and name your pictures correctly
• don’t send me fucking photoshop files. They’re unusable unless you do the exports and I’m not paid to do your job
• be flexible, or read the HIG
• listen to the dev when he points out the differences between the various screen sizes
• things you cannot storyboard or explain in plain English have little to no chance to look and feel like you imagined it would. Devs do not have access to your unconscious brain - thanks god for that
• things that cannot be skinned in UIKit are probably a bad idea and will cost you in dev time. I don’t care if it’s really simple to do it in photoshop, it might be a real shit task in objective-C
• when I’m doing contract work, I’ll make sure to make you or your customer pay for those 2 pixels that denature your “art”. Particularly if the solution is not obvious
• read a few posts on the icon dimensions. Don’t round the corners, iOS does it for you. Heck, download one of the [insert number here] templates off the web.

It’s a wide world

Let’s start with the obvious: it’s a World Wide Web, and we tend to forget about it while being entrenched in one way or another in our lives and work activities. It sounds like I’m going to be apologetic, which is not frequent, and I am. I’ve recently developed and published through the AppStore an app called TipToe, see it here and follow the link to the store — $1, cheap, indispensable (it sure is ;-). So, that’s a cute app that lets you search Bing and Blekko, and aggregates the search results in a nice table. And I’ve put in a minimal in-app browser (minimal, yet complete) which is lean and fast.
The app has been featured on [MinimalMac](http://minimalmac.com], we proudly sponsored the RSS feed the week of the release of TipToe (entry on the 4th of April), and it was picked recently by LifeHacker. Life couldn’t be better (well, actually, we could always sell more, but that’s another story). Couldn’t? Sure it could, and should.

The glitch

A few hours after we got featured on LifeHacker, I received a moving email from a user who purchased the app, regarding the lack of accessibility of TipToe. This user is visually impaired, and complained that VoiceOver in TipToe was inexistent… Well, actually, being a really sweet person, he sent an email noticing that some of the buttons were not customized for VoiceOver access. Indeed, that’s one of those emails that hit you pretty strong in the face, and for two reasons. One, I remember reading a very good blog post by someone visually impaired explaining how the iPhone gave him back a sense of sight by letting him know which colors were in front of him. This post moved me (note to self: gotta find it in my archives). And two, there was an excellent post from Matt Gemmel here that describes how easy and important it is to make your app accessible. So, shame on me for forgetting about it, I read that piece, enjoyed it and bookmarked it for using it later. Only problem is I skipped using it. Now, pretty much like anything I do, I just considered that shortcoming as an engineering problem, ie. a mistake that should be fixed. Off we go, let’s add Accessibility to TipToe. Matt having indicated that it’s easy, I shouldn’t have many problems to implement that. Quite wrong, but here’s what I did in the end.

The elements to be made accessible

I’ve made a quick capture of some screens from TipToe, and here we’re going to address two kinds of tips: 1- making the table cells more readable, and 2- accessing some elements that do not have their Accessibility property reachable from Interface Builder (IB). The latter is probably the most interesting case. In TipToe, I had to trade the Navigation bar at the top of the view for a standard toolbar. Basically, I wanted to define an empty button in the center of the toolbar so that I can make the web address bar disappear on touch. That’s a neat trick to maximize the screen earl estate, and it saves me from a scroll view, which I don’t like when browsing (always need to scroll back up to get the actions, and I wanted the actions button to be always visible, as they open the share dialog). There’s certainly other ways to achieve that, but it was the easiest and quickest to implement. You’ll notice as well that I haven’t circled all the elements on the left hand side of the picture. Basically, the UITextField for search entry and the information button at the bottom right are already addressable in IB, so no need to do a fuss. This case is well documented in both Apple’s Guidelines and Matt Gemmel’s post.

The table

There’s a good hint in Apple’s Accessibility Guidelines, which I shamelessly use here. It consists in concatenating some fields displayed in your cell in order to make it more easy for the robot to read.
Here is the snippet for the table:

1
2
3
4
5
6
7
8

UILabel * titleLabel = (UILabel *) [cell.contentView viewWithTag:TitleTag];
UILabel * urlLabel = (UILabel *) [cell.contentView viewWithTag:UrlTag];
UILabel * descriptionLabel = (UILabel *) [cell.contentView viewWithTag:DescriptionTag];
titleLabel.text = [displayTitle objectAtIndex:indexPath.row];
urlLabel.text = [displayURL objectAtIndex:indexPath.row];
descriptionLabel.text = [displayDescription objectAtIndex:indexPath.row];
cell.accessoryType =  UITableViewCellAccessoryDisclosureIndicator;
cell.accessibilityLabel = [NSString stringWithFormat:@"%@, %@", titleLabel.text, descriptionLabel.text];

So, quite simply, I’ve got a custom cell which displays the title (re-formatted to make it homogeneous in my app, the url (ditto) and the abstracted content (that’s the description label). This is done in a most classic way using three UILabel (Lines 1-3), for which I’m assigning the .text property after, while extracting the search results from the main table of the class (Lines 4-6). Now, the catch is that VoiceOver reads everything in a cell when it is tapped. And clearly, you do not want the url to be read, it will literally read “h t t p column slash slash etc…”. Not really pleasant. Instead, we’re just merging the titleLabel.text and descriptionLabel.text, and assigning the result to the cell.accessibilityLabel (Line 8). This is now the text that will be read when the cell is tapped. That was pretty easy, let’s get to the hairy section now.

Bar buttons

I’m getting away in the Display view with only changing the viewWillAppear method, such that:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

-(void)viewWillAppear:(BOOL)animated
{
    UIToolbar *topbar =(UIToolbar*)[self.view viewWithTag:200];
    [topbar setAccessibilityLabel:@"Top bar"];
    [topbar setAccessibilityHint:@"Navigate search results"];
// 
    UIView *topbarbutton1 = (UIView*)[topbar.items objectAtIndex:1];
    [topbarbutton1 setAccessibilityLabel:@"List"];
    [topbarbutton1 setAccessibilityHint:@"Goes back to search results"];
    UIView *topbarbutton2 = (UIView*)[topbar.items objectAtIndex:2];
    [topbarbutton2 setAccessibilityLabel:@"Share"];
    [topbarbutton2 setAccessibilityHint:@"Opens share options"];
//
    UISegmentedControl *segmentControl = (UISegmentedControl*)[self.view viewWithTag:202];
    NSUInteger buttonCount =  0;
    for (UIView* thisView in [segmentControl subviews])
    {
        switch (buttonCount) {
            case  0:
                thisView.accessibilityLabel = NSLocalizedString(@"Down",nil);
                thisView.accessibilityHint = NSLocalizedString(@"Goes down one entry in results list", nil);
                break;
            case 1:
                thisView.accessibilityLabel = NSLocalizedString(@"Up",nil);
                thisView.accessibilityHint = NSLocalizedString(@"Goes up one entry in results list", nil);
                break;
        }
        buttonCount++;
    }
}

Now, there’s plenty to discuss here. The main point is that all those elements do not have their accessibility property accessible from Interface Builder, so we’ve got to be a bit smart. We’re going to use the same trick for all the elements, which consists in accessing the accessibility properties of the view that contains the element.

First up: the top bar. That’s a UIToolbar, I’m accessing it through a tag. Nothing much to say about this… except that we need that UIToolbar to be defined for the next step.

Second: let’s get into the bar buttons. Once you know how to do it, it’s evident. We’re just picking up the UIView that contains the button (Lines 7 & 10), and doing so from the UIToolbar list of items. These items are numbered in the order they are displayed in the IB, starting with 0. In my view I’ve got a space before the first button so my button1 is at index 1 (Line 7). The all shebang is then over, as I can set the accessibility label and hint of my newly defined UIView (Lines 8-9 and 11-12). Simple enough! Unfortunately the UIBarButtonItem accessibility cannot be accessed directly from IB, but this does the trick in a few lines.

Third: well we’re got this damned UISegmentedControl. Let’s face it, life would have been much easier if I had kept the first version of the app (alpha), which had two separate buttons. But no, I had to get it with the look and feel of Apple’s Mail and Safari, which use this UISegmentedControl. Now, the same trick is used, with a twist. We start by picking up the UISegmentedControl (Line 14), and then we’ve got to navigate through its subviews (Lines 15-29). We’re doing so using a for loop (Lines 16-29) over the [segmentControl subviews], and together with a simple switch statement (Line 18) we get our subview accessible. In our case, we’ve just got two segments, but this could be used for more. That’s all there is to it…

Summary

That was a quick rundown, and hopefully this post will be obsolete in a future release of iOS. Quite unfortunately, the doc on this subject is very light, so I hope it may help someone. The take-home message is simple:
- if the element has its accessibility property available in IB, just use that;
- if it does not, I’ve either covered the case here, or you’ll have to dig through your elements inheritance and find the view for which you can set-up the accessibility.

Questions and comments are always welcome, though I’m afraid I don’t have much time to check your code these days… So, please don’t hold it against me if I can’t respond fast enough.

Well, that’s it, we’re almost through. I’m going to step in a plane that will take me back to France, if everything turns right, and it’s a good time to reflect on this past year. Or as good a time as any. Edit: completed that one on the plane, it’s raw and not edited since then. Enjoy!

Personal matters

Let’s start with the one thing I can be proud of, the most important: this year, as the last, and the next, I have loved my wife and my son with all my hearth. And will keep going on until theme of times. Beyond a few sicknesses, mostly brought back from School, we have been ok. Just a small alert for Ivanna at the end of the year, but this small surgery went all right. We have bought a car and a rabbit, Attila, who is missed dearly when we are traveling. Vlad is surprising us everyday, he’s doing better and better in school, actually much better than I was (I’ve never been social, won’t surprise anyone). That’s it for the main points, and I’m not into letting too many details about our life on the internet.

Professionally: transitions

Professionally, the year has been interesting… and quite deceitful as well. We’ve been able to launch 3 products on the market, two of which have found customers. I am deeply thankful for our customers, it means a lot to us that you believed in the first versions of these softwares.

The rotten fruit: where is NIL going?

The bad product, by which I mean the one that did not sell at all, was an online journal, a compilation of the patents that are coming out related to Nanoimprint lithography. We did put up an online store for it, and sold: zero copies in the first two months! Given that about 50 people were downloading each issue, which had the first and last page free, this was a bit of a disappointment. I’m not sure whether we did something wrong or there was just no market for this. The only comparison I have is the online newsletter from our friends at NILT, which has stopped as well (as far as I can see). This is really problematic to me, as it shows poor involvement from the community - is there a NIL community out there? The last NNT conference seems to disprove that, as most of the US participants stayed in the US. True, they’ve been hit harder by the financial crisis than others, but they started it. Talking about the financial crisis, despite all the bullshit we have heard, most Europe and the US have not yet recovered. Asia is different altogether. Indeed we got our first customers from Asia, and would probably move to open a permanent outlet there if our research was not mainly funded by the European Commission. Anyway, 0 copies was too little for the two days it took to put the webzine together, so I axed it quickly and neatly. In the same vein, I started a group in LinkedIn for NIL, that a few people seem to follow, but very loosely. No one really reports progress, asks questions, and after a few months being the only voice in there I gently quieted up. My message there: scientists are not social, which we knew, I just did not realize that they were so stubborn and uninterested people. It seems that anything that does not go their way is a bad thing, to be ignored first and foremost. Which is funny, because this technology, which is one of the most promising out there for future nano-enabled products, may just fail because of this: poor management of tech, poor interactions, too many patents competing on poorly chosen grounds, and in the end a very poor representation towards industry and thus general public. You would need to scan the faces of most of my estimated colleagues when they are told that they should disseminate to the general public to see what I mean… This inevitably appears like a burden to people who are, I agree, already stretched thin (very thin) between research, publications and conferences, and writing grants to fund further research. I do not think that 2011 will see any advances in the way research is funded, but honestly the balance between seeking funding and actually doing the work is less than easy to find these days. And it’s going to get worse with all those management goons now involved — I will put together a real post on management of research and the issues it raises, promised. But that’s the way things go, we’ll see how this story ends.

One software out, one!

That said, we got our first product out this year, the NIL Simulation Suite, which is quite revolutionary. While we are working towards extending it in 2011, it is full of good ideas, a really powerful solution to simulate a whole NIL process in less than a minute, and should do great in the near future. Sales were not as high as expected, but our major customers in the US dropped out due to funding restraints following their financial crisis. That was not so cool, but encouraged us to look for other revenue streams. Meanwhile we have worked a lot to get a full 3D solution for the NIL problem, have succeeded. So, the next version will have both 2D1/2 and 3D, from which we will only build additional services - the basis being there. We have worked a lot on 3D representation of datasets, and feel we are going the right way. We have a few exciting ideas for 2011, which I hope will see the day. That said, again, we got our first customers from Asia, with good returns on the usability and performance of the software. Importantly, we got very little requests for help, which means that the product is robust enough, and that I do not need to be waken up every night (due to time difference… If you love to sleep, do not offer 24/7 phone support). With another few good leads on the way, Sales should increase this year. In fact, we have done so much this year that it seems like it was forever when we released version 1.0 of the NSS, when it was only this year. All together, kind of good, and I am really excited to build a few critical 3D cases that enable to distinguish between coupled effects. We’ll see more (a lot more) about this in 2011.

I’m not sure I’ll ever get done with this book

The only regret I have is for not having more time. All things put together, I think I have a basis for at least 6 full papers, which I haven’t been able to write. Then there are these book deals: I agreed to write one a few years ago, and am half-way done only, and have been approached by two other editors to get something going. Now the first deal was OK, but the publisher sold to another company, which meant that I had to change editor. Which I did not. As to the others: no time, and without wanting to be mean: you are not going to milk me with a 10% deal anymore guys, even though I’m not doing that for money, I hate being taken for an idiot. But anyway, those are remnants of our life in England, and we’re up to more exciting stuff. Particularly about tech!
I do have one idea about it though, and it’s pretty much tied to iDevices publishing. Take it that way: now that I’ve put together a good text editor, I’m wondering if it could not be turned into a web-learning publication assistant. And it’s a good exercise probably to try and extend Edito in that sense. We’ll see.

2010 tech has been great

iPad

It’s hard, like really hard, to think that last year at the same time the tech pundits were still speculating about a possible Apple tablet. That’s right, last year, when 2010 hit the clock, no one was sure that the iPad was coming. If there is one piece of tech that has changed the world, it is the iPad. It appears so obvious today that a touch interface should be just like this, with a screen about this size and this sensitivity, with apps launching this fast in one single mode: full screen, the beauty and simplicity of split-view controllers, pop-over controllers and the way they dismiss each other, the way interface rotation is handled, the long battery life and crisp screen, all these things….. All these things came out this year! When Steve said that the device was (among other superlatives) “magical”! He probably meant it, but we were not listening. After holding one for about 5 minutes in an Apple store, I knew that 1- it is magical, and 2- I wanted one. Here is the thing: if you have ever used a tablet PC and think that you know what an iPad is, you are very wrong. It would be like a guy claiming to know how it feels to drive a Porsche 911 turbo when all he’s ever driven is a Ford Focus: it’s got nothing to do, even in the same sentence.
Wanna know how much it changed things? I’m on a plane right now, got about 10 hrs of battery life to just type this blog. It’s easy to pull out, and I don’t feel like I’m using a computer. I don’t feel like I’m using an oversized iPod touch, either. You had to be a jealous moron to write that, but such is life. To tell the truth, I’m not sure people in Cupertino even expected this device to be so successful. But you’ve got to give it to them, it was perfectly addressing a gap in the market. Fr us, the iPad has become the take everywhere device, or have movies for our Son on it, games aplenty, books and magazines for us, and I’ve been developing for it, of course. Thinking about it, I’m not often thinking about it. Here I am, just read two comics, watched a movie and killed a few feral trolls on the way, and coming back to the blog entry.
But yes, that last point is also new this year: when I held that iPad for the first time, I knew that I had to program it. That must be the touch interface and the way you are immersed in the environment that drove me to it. That was a quite sweet experience.

iOS4.2, Xcode

Well, this one was long awaited, and finally came through quite ok. What did not come out is the new version of Xcode, which is still in beta. That’s a bit of a pain, because we’re running concurrent versions of it on several machines, but it should come out next year anyway. Now, I have taught myself objective-c this year, which is maybe the best thing I’ve done. It is simply a beautiful language. Do not listen to c-nerds or c++-nerds, or anyone telling you that this or that language is much superior. Coming from the more immediate background of java development, I can assure you that if objective-c ran on all the other platforms, ie. non-Apple, I would never use another programming language. A few things seem a bit odd at first, and then after a few days of programming, when everything starts falling into it’s rightful place, it is just a pleasure to see how intuitive this language can be.

Edito (3 versions)

I’m currently typing this post in Edito, the missing Markdown editor. Well, it was missing for like 3 days because the competitors cam out right after, or maybe right before for one of them. There are a few guys who got the same idea as I did, and I cannot blame them. Honestly, when you have used a regular text editor such as Pages on the iPad, you know that something is missing. I’ve long been interested in markup languages, being myself a LaTeX user forever and a famous MSWord hater¹. So I went on and took a month or so to learn obj-c as I programmer a Markdown implementation for the iPad. The goal: teach myself obj-c essentially, and sell some licenses if possible.
A few very positive things have happened beyond simple learning, the most important being that I have made some new Friends and relations, and been able to share and exchange with some really great people. Bloggers and the Apple community as a whole have been outstanding in helping me along the way, that includes dev a little, constructive criticism, beta testing, reviewing the app… Really you have to live through it to realize how great this community is, which is a new feeling for me ². That’s the main reason why I am not going to port Edito to any other platform: our early adopters have been really encouraging us and supportive, to the point that after the first glitch of version 1.0 was corrected (in version 1.1), we introduced some nice ameliorations in version 1.2 as well. I must confess that this app has become quite practical, with TextExpander Touch support - seriously you need to check that out! - and a bunch of other cool features. I’m not even sure I’m porting it to iPhone. Ivanna keeps breaking my balls with going for an iPhone implementation, but honestly I do not see myself typing this blog post on an iPhone. Yet, she does! Since I’ve bought a wireless keyboard I must have been able to use it twice? Otherwise she has completely confiscated it, and is using it with her iPod touch to type most of her writings. And she’s writing a book. She just said that being a mother, she needs to pull the device from her bag whenever she has time, and there you go, for her the comfort of the keyboard is much more important than the size of the screen.

Edito in 2011

Our next update will see Multi-markdown, the extension of Fletcher Penney, partly implemented. At the moment I got the footnotes working nicely, the equations thanks to MathJax, and I’m trying to sort out the references to bibliography, although it is hard to understand why anyone would use those in an HTML document — notice that MMD is also suited to convert to LaTeX, this is probably why they are supported. And then I’ll get close to the heart of my users and provide DropBox support. This is the single most requested feature, but I must confess that 1- it has been difficult to implement and 2- I hate 3rd party services like this: what happens if they decide to close it down, or get acquired by Yahoo³? Add to that importing pictures, importing your own styles, and printing/exporting to PDF and you’ll have a clear vision of where we will be at the end of the year. I’m also quite convinced that Apple is going to surprise us again, particularly with that huge data center, which I hope will raise the bar of the iDisk. Which honestly needs raising!

The top fuck-ups

We’re no longer in ‘95, and Microsoft deserves the palm of bad choices this year. I can’t even begin to understand how they got to that point. Lazy or stupid? Indigent or sufficient? I talked about the short lived “NIL outsider news”, but that was still a much longer life than the kin, whatever the spelling, we did not have the time to catch it anyway. This Microsoft device came and went in about a month, I don’t even think it has been available in Europe. I think they sold less than 10’000 devices or so. And while I’m offline right now, it seems to me that this came after CES2010, so it was this year. Seems like prehistory. Who in his rightful mind would put out a device that is essentially a pager — a technology that RIM replaced 10 years ago.
Then same player shoot again: who in his rightful mind would show a shit tablet PC running a PC system just to be the first to show the Tablet? Well, Ballmer did. Of course, Steve’s demo a month later of the iPad must have left him sobbing or self-reassuring himself. I find it funny in retrospect that even when MS was almighty, Ballmer never got his first name back in the industry: there is only one Steve. To MS’s credit, though, they came up with a new OS for mobile devices that is not a rip-off of the iPhone OS, and that does not suck too much, although it’s really late. Man that must be hard to be a MS employee nowadays, when all the creativity is swallowed by a giant vortex of bad management. I’m with you guys, been there, done that, it sucks, move out and choose your next gig carefully. I’ll tell you the positive of it: never again you will be surprised when management fuck up comes to tip the balance in an unfavorable position. I’m able to smell it from afar now, the first sign is that all internal decisions motivated by rational choices and very highly qualified panels, a few hundred to thousands man-hours spent in meetings (know what I mean, right?), all those would not be logic to a 5-6 year old⁴. You’re embarked in the bad-logic tunnel, can’t seem to get back on the right track. Worse thing of all: each time there’s a split, you’re taking the wrong way and your guys are pissed because the all said take left and you went right. So that’s life.
Then pretty high on my list there’s that CEO of HP who got thrown out because he had his mistress on the payroll. Man, you’re serious? Come on, don’t give me that crap! I bet that all the board has some flesh on the payroll, one way or another. Wouldn’t that be that this guy fucked up the computer division so bad that they had to ‘let him go’. Or “sunset” him, as you wish.
By thus way, talking about HP, Yahoo is another big fuck up. Cant understand how these guys bought companies, honestly. Must have been a bunch of incompetents who saw everything as fine as long as the money came in. Now, is it me, or the worst CEOs of the story of the electronics industry have been two (women) bitch on wheels? Carol Barz and Carly Fiorina. Carly was quite a winner on all counts. From day one, people new that she was going to kill the company. They still have not recovered. But that’s a giant of the industry, so they will eventually recover, having been stripped from their scientific instruments (no one seems to remember that Agilent was part of HP before at nutter decided to cut it - another good move Carly) and probably the computer division (seriously, look how they’re made nowadays, they look like cheap plastic. I’m ashamed to see that, when I think about the workstations they were delivering to my office 10 years ago for testing). I’m not sure that Yahoo will survive Carol though. I sort of fail to see where their assets are right now. Apparently they still represent a lot of traffic, but that’s so easily gone… And Google is out for blood.
One of the most surprising things to me, year after year, is that everyone is looking at the Apple-Google riff and thinking “Google wanna kill Apple, that’s the whole Apple vs MS going on again, Apple is gonna die”. Now now, there are a number of mistakes in this statement. First of all, like all good geeks, the Google board is playing a giant game of Risk, where they end with world domination. They do not dominate Apple, nope. They end with dominating everyone. Meaning that Android effectively went after WindowsPhone7, Palm OS (another big fuck up for now), RIM and the webos, symbian, etc… I’m not sure that iOS was even top of their list when they decided to get into the mobile market.

Remember Ericsson?

No? You don’t have a hearth then, or you are really young. In their own way they blew it, and were bought by Sony. Or bailed out, as you wish. In the end anyway, they were cut into small pieces and sold separately and I’m really not sure that there’s something left from it today. Now there is a strong parallel between Ericsson and RIM on many points. If you go back to the end of the 90s, Ericsson had a market to kill for: phones for professionals essentially. You would not pick a Nokia that looked like a piece of crappy plastic when you could have a nice shiny black ABS phone from Ericsson. Drop a decent OS in there and some easy IT configuration, and you have a winner. Remember that we did not think about having the internet in our pocket at that moment. Hell, I got it with my Nokia communicator in 2001 I think. And it was crap. But anyway, Ericsson went to hell very fast, by being made obsolete in terms of tech AND brand. Nokia had a go at them, with their shit plastic shells, customizable, at low prices, and an OS that was easier to use. The swedes didn’t realize their were hit, and puff they were gone. RIM just scraped the remains (corporate users), and that was that. Now I fear that RIM is going down the same way. Honestly, their main tech is obsolete, their handsets are not the best looking in the world, and they haven’t innovated for quite a while. I’ve looked briefly into the new SDK and what you’re able to do easily, and the apps are just web pages. OK, HTML5 and CSS3 go a long way, together with standard JavaScript support, towards being able to do some pretty complex and complete stuff, but it’s damn slow in the end. Plus, who’s gonna pay for something that I can crack before breakfast in less than a minute — and believe me, I’m not fresh in the morning. Plus, who actually thinks that bandwidth is going to come in unlimited quantity?
I’m quite dubious on the future of Android as well. See, Google technologies do not fare well after a few years. Is there something that survived the past 5 years beyond the search engine and gmail? Maybe google docs, but honestly: there is no contract between you and Goo to support the software that helps you open your documents or access them. It’s free and you are paying with you time and attention — these guys are marketing YOU. In any case, Goo and others can withdraw and/or close their free servers anytime without telling you, and they’re most unlikely to flinch about the idea that you are pissed. But I digress. Again, I sort of fail to see where Goo can find the interest to give away it’s OS and maintain it for x different handsets. In the short term, yes definitely, can do, but the long run: no interest. And by the way, MSWindows 3.1 was more opened than Android, even though we did not get the source code. I don’t know why I’m thinking about that right now, if only because my latest analysis of the mobile OSes would tend to give two winners in the end: Microsoft and Apple. We will see in 2011, but if MS allies with Nokia for real, we have a big contender there. And seriously, WP7 is not that bad, the market place is a complete rip-off of the iTunes store, and the SDK is ok if you like visual-c++. But basically, devs will be able to make money on that store, and you can trust MS for easing the pain to sell licenses and bundling apps no one will ever use with essentials. I don’t really care anyway.

Some engineering goodies

2010 has been a year of revival for the Mac, with two essential pieces of software: Autocad and Rhino3D. While the former has been out for a few months now, the latter remains in Beta, but is quite close from release. So here’s my tip: if you are an architect (first I don’t see what you are doing here) go get yourself a 15”MBP with a decent, 24” minimum screen, and run Autocad on it. The speed and the interface are just amazing compared to the PC counterpart. I can’t be sure why, my best guess is that they started from scratch and rewrote most of the software instead of porting it. Without the overhead from the past, one’s got a pretty nifty tool. And the interface is gorgeous. Really, really gorgeous. One recommendation though: use the magic trackpad if you really want to achieve the best control of Autocad on the mac, the magic mouse if way too erratic for this kind of software control. Rhino isn’t a bad software either, I really enjoy the interface, and despite a few bugs still there, will keep on trying it. The thing is, Rhino will probably never be an engineering tool per se: no libraries of parts, standards, no BOM, etc… But it enables very fast drawing of 3D shapes using NURBS, which is perfect for a quick rendering (I like the new engine) or rapid prototyping. And of course, to produce complex 3D shapes. If only SolidWorks and ANSYS went the same way, we would have everything one ever needs for good engineering work. But no, they’re putting up a strong resistance. Yet, for 2010, that’s not too bad — particularly after such a long wait. It remains to be seen when we will be getting Stark “Iron Man” technology, with interactive 3D displays. And by the way, 2010 was also the year of Iron Man 2, a great sequel. Haven’t seen many good movies this year… And the other much awaited sequel, Tron Legacy, really did suck.

I’ve been looking recently at a decent and elegant way to replace portions of a string of characters. While searching and replacing parts of regular strings, for example “foo” by “bar” is a built-in functions of iOs since the beginning, doing the same for “[^whateverfoobar]” in a sentence is clearly a pain, as one’s got to find the first two characters, the last one, then hold a copy of “whateverfoobar” and perform operations on it. So, is there a good way to find custom delimiters? Answer is YES since iOs4.0, where regular expressions have been implemented. Up to that point, devs were using a RegExKit, which is no longer needed, and may indeed cause problems when submitting the app to the AppStore. But anyway, one can do without now.

So, Apple introduced in iOs4.0 a new class, NSRegularExpression, which is exactly what we need to deal with such “[^…]” expressions easily.

I do not want to get into the syntax of regex, but a few points must be mentioned before looking at our example:
1. iOs follows the ICU convention, which can be found here;
2. This is all cryptic, I have found a good user guide on the web, powered by Zytrax. It features, around the middle of the page, a javascript utility that lets you test your regex on whatever you enter in the boxes; 3. There’s a twist, and a careful-careful-careful one, in that Apple chose (can’t know why) not to implement the standard C escape characters, but instead seems to have chosen the C++ convention. In other words, where “\^” is used to define/search the caret in C and standard regex, you will need to use the double backslash before your caret. In obj-C, the correct expression is therefore “\^”. I have not checked for all, but this works in this example.

Let’s look at that regex now. It looks like this

\[\^.+] 

where the first character, a bracket “[” needs to be escaped by “", ditto the second “^”, follows the (very) cryptic “.+” that means any set of characters but at least 1, and the closing bracket “]” does not need to be escaped. That’s the standard, and we can check it on Zytrax, which results in:

Pretty cool uh? This little script gives us the expressions found matching the regex, enclosing the first one with <>, and then gives the other occurrences in the string. With the small example we chose we can check that double brackets without the caret “[foo]” are not taken, nor is the empty “[^]” chain of characters. Now, from what I’ve said before, in Objective-C, we need to escape characters a bit differently, such that:

\\[\\^.+]   

If we do not do so, we’ll get get a Warning “Unknown escape sequence ‘\^’” which bugged me for a while (hence this post).

Here’s a small bit of obj-C code that demonstrates the use of our newfound toy:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

NSRegularExpression *regex = [NSRegularExpression regularExpressionWithPattern:@"\\[\\^.+?]"
                                                                       options:NSRegularExpressionCaseInsensitive
                                                                         error:&error];
NSUInteger numberOfMatches = [regex numberOfMatchesInString:content1
                                                    options:0
                                                      range:NSMakeRange(0, [content1 length])];
NSLog([NSString stringWithFormat:@"%d", numberOfMatches],nil);

NSRange rangeOfFirstMatch = [regex rangeOfFirstMatchInString:content1 options:0 range:NSMakeRange(0, [content1 length])];
if (!NSEqualRanges(rangeOfFirstMatch, NSMakeRange(NSNotFound, 0))) {
    NSString *substringForFirstMatch = [content1 substringWithRange:rangeOfFirstMatch];
    NSLog(substringForFirstMatch,nil);
}

And that’s it for now… Note to myself: I need to set the code display properly here…

Well, I’ve read pretty much everything that came out about the newly announced Mac AppStore, also known as MAS, and there is definitely more than meet the eye, in my humble opinion. There are some very good points that have been made by Dan Frakes of Macworld, and a good discussion came out during the Talkshow, hosted by John Gruber and Dan Benjamin: these will not be repeated here. Yet, I’m left wondering if we are not led into, at best, a poor understanding of what is really at play here. Now, to a few points, and let’s try to connect the dots.

Apple is building the mother of all servers

This is the beginning and the end of the “conspiracy” theory. I’ve been talking to several observers lately about the probable use of this server farm, and the consensus seems to be a streaming service for iTunes. If there’s something that Apple/Steve Jobs has taught us time and again, it’s that consensus is generally wrong at predicting what is coming. Therefore, as much as this seems reasonable, and probably in advanced implementation - although I can see some DRM complications looming - this is probably not even the beginning of it. Is Apple planning to use this plant in 10 years, and use it at 1% of its power for now? Is it, as the Bro’Show describes, a “Death Star”? Come on, who thinks that Jobs or Apple are eternal? I’m sure of one thing: they want to use the facility, and use it for something soon. They would not build for nothing, just before they’ve got cash right now.

Apple’s strategy goes along mobile for all

This post is entirely written on my iPad, which is becoming quickly my preferred method to enter short, unconnected lumps of text. Basically, blog entries. Thanks Edito for this - which is getting better by the day. Earlier this week, with the announcement of the MAS also came the new MacBook Air, which is a cutie (don’t get me started on this), but is breaking with many industry practices. People do not seem that much bothered/amazed by the fact that this inception of the MBA marks the end of the race to processor speed. For the first time in 30 years, Moore’s law is defeated, and this may make sense. In terms of power consumption, in terms of thermal management, and so on and so forth. Yet, the MBA becomes even more portable, and achieves great battery life, and faster opening of software and most operations. Sure, the rest of the line has been refreshed lately, particularly the Mac Pro, but this was a very late release (although a good and appreciated yone). Sure, the MacBook line was refreshed, and the specs have been upped. But the biggest news last year were the iPad and the iPhone4. Which both pack more power than the workstation I was working on 10 years ago. That’s right, think about it in those terms: those mobile devices are more powerful than the SGI workstation I used to program and solve finite elements problems in 2000, which costed a whopping $20’000. I’m also thinking that these devices pack the new Apple A4 processor, and have just been disappointed not to see a multi-core version of it in the MBA. Then, there’s the new OS coming…

OS X Lion , Xcode 4

Mobile, portable, touch integrated (?), with an interface closer to iOs!!! Come on, I’m not the only one seeing that iOs and OSx are truly converging, but converging to become what? Then, why is Xcode 4 delayed again and again? I know that Apple wants products to be perfect when they’re coming out, but XCode 4 is not a bad inception by all means. Yes, it’s buggy at some points, but nothing that a good overnight build could resolve for a few months. And again, the usual way is to get the software out there, and correct for bugs along the way while they are found. My take on this: while there are a few things that should still be ironed out before the release, the reason why we have not see this (excellent) piece of software released is that it is not complete. What’s missing? Essentially things that the new OS will support, like the whole touch interface. That’s right, all our beautiful UI touch functions, and most UI classes integrated with the OS X! At last, a way to implement a universal version of softwares developed for the Mac platform. Come to think about it, the interface needs to be designed differently, but I can see ways to do so quite easily (I mean, programmatically, it may still look ugly of course - graphics have never been my strong point).

What’s our take

My best guess differs from our blogger friends. Here’s the plan:
1. Update Xcode, get the convergence all right, and unify the touch interface. See the excellent entry of Patrick Rhone about how Apple is training us to the touch interface/world. How far are we? We’re pretty close, since Apple introduced its new line of mouse, and of course the new trackpad.
2. OS X Lion is coming up, I think besides the changes to the UI we’re up for a few new functionalities, through the MAS, that are going to rock our boat. In store: syncing of course, in app sharing and communication. Frankly, I can’t wait to have a window with my chat or better even a FaceTime session with a collaborator, discussing the document that is being edited directly. What a feast it will be when working on large proposals for example.
3. The MAS, and the issue of DRM: one of the points that has not been discussed in detail is how the heck is Apple going to stop people from copying the software they are downloading and installing through iTunes? On the iDevices, it’s easy: the only way to install an app is through iTunes (unless you’ve jailbroken your iDevice of course, naughty). Now this cannot be true, at least at the moment, for the Mac. As a result, there is no way for now to include a license key in what’s going to be distributed. Does that mean that we’re going to have to make every app free, and be supported by in-app purchases or iAds? Does not really seem like a good solution, at least to me, at the moment.
4. Connecting the dots: what I think Apple are up to, and is the future of computing, is that Apple will not only stream media from their servers, but also stream apps. In other words, in a perfectly connected world, the server will not only hold your data but also hold your apps, whose execution will be taken on the server. This makes little sense for the first generation of apps we are running on our iDevices, but that’s just what it is: a first generation. What we have, basically, is a string of apps that are good at doing just one thing well, and that explains part of the success of the iPad. The next generation of apps, I foresee, will be way more complete. We’re beginning to see this kind of app, where the APIs of other apps can be integrated easily into your own. For example, TextExpander Touch is integrated in Edito and many other editing apps. And it does not take a huge effort to do so. Bear with me: why do you need a Death Star server? Answer: to support synchronous protocols. And this is the key enabled for streaming apps… Nothing like what we have now, where asynchronous protocols almost exclusively are used.

Conclusion

Apple is controlling distribution of the apps, and the only way for them to fully control the rights, as we cannot see a licensing scheme looming, is to control execution as well. The one thing that will confirm that move is Xcode, where we should see at some point a new set of functions for server execution and, in particular, multithreading and distributed computing. The big picture is to move most of the large computational effort to where it’s better taken care of… not on your portable iDevice/MBA, but on large servers with unlimited computing power.

That’s all Folks, and we shall revisit this post at a later date, to see how wrong we could be. Hopefully we won’t have to go through a claims chowder!

We’ve just seen in the previous post Building Edito - Part 2 that we are following a 5-gated process to developing our app. By the way, the name popped-out later in the process, at the early stages I just called it iMarkdown. With most of the stages 1 & 2 well engaged, the big remaining task to get into stage 3 is to draw a list of features. Because Objective-C is object oriented, this list will likely turn into our main classes.
My method is the following:
1. get to a white board
2. start throwing ideas on it 3. second round: organize around one central idea
4. third round: time to introduce some logic into this mess. Which feature derives from which, essentially.

Now, this is the tricky part. When you’re done, make a clean representation of what you have, and distinguish between what is horizontal and vertical. Let me explain. Horizontal is everything that the user is going to interact with. Vertical is the “engine” of the software, ie. in our case the Markdown conversion, reading and writing to a specific format, the various libraries stored or called. In other words, the graph you will end up with is in two parts, where the first one (horizontal) gives a pretty good picture of the app UI, and the second (vertical) the built-in functionalities. The vertical part is easy here, we just want to convert ASCII to HTML following the Markdown syntax. The horizontal part, well, is depicted on the figure below.

On this pic we have everything we want and more. You can see that I’ve drawn an ellipsis on the features that we’re keeping for the version 1.0. That comes right after putting everything down on paper, and it’s the analysis of needs vs wants. On the graph, I’ve got all I want — and a potential customer may want or expect from such an app.
We could group everything as essentials and non-essentials, but that’s probably a bad calculation at this point. For instance, what would you do with an app that can just type, open and save documents? Hate it probably, or not use it more than once. What we’re set to achieve is an easy way to replace all the operations we’re doing in our favorite Markdown editor on our laptop or mainframe computer. We’re generally using it to produce HTML documents. Those generally contain links, images, and I’m constantly switching (at least I was, in the beginning) to a Markdown cheat sheet. All of that I want in my app. Then, I want to be able to send those documents. Let’s face it, iPad is not so cool to exchange documents, and iOs 4.2 is not solving that problem apparently (we would have been told otherwise). So, eMail gotta be a feature. In the end, I’m proposing to leave out (for now) what brings little (word count), complicates the operation (importing USER css) or just is impossible to support - I do not have time to spend checking the css files of users - and what I can’t implement in say 2-3 days. That includes syncing to other APIs, the spell check, and importing pictures.
This last one is a tricky one, as I’d like to be able to use pictures from my iPad library, and just include them naturally in the document. The best way to do it is probably to convert the picture to Base 64 and paste it in my document, but it’s going to look truly ugly, unless I find a way to make it magically disappear while being retained in the document. That’s actually going to influence our document format, this idea. Syncing to other systems was probably the toughest one to reject, as I know everyone wants these features. Yet, bear in mind I’ve got to learn Objective-C first, get to writing my own app, and get it accepted on the App Store, ie get through a full process loop, before I envisage to use some private APIs that may be tied to specific conditions…

All of that being done, I evaluate a ball figure of 2 months to get this thing up and running. I don’t have much more time, and since it’s not rocket science - I would do it in Java in a quarter to maybe half the time probably - this should be OK. The main difference with doing it in Java is that 1) I don’t know the language, although I now have a pretty good idea of what it looks like after browsing the first few chapters of reference books, and 2) I’ve got what appears to look like a solid, fully populated dev. environment.

Next part will be quick, it will just give references I used to learn Objective-C. Two weeks were good enough to grasp most of it…

Edit:

There are two important things I forgot, and that came afterwards. Well, in fact, 3.

1. there are some accessibility facilities in iOs now, so that a visually disabled could use the software. That comes at the price of a small effort, but since we’re aiming (and have achieved) at a clean, uncluttered interface, this should be possible. And give me a certain peace of mind;
2. producing PDFs… This does not look like an horizontal only task, and that’s why I dropped it originally, although I thought about it - and forgot about it. That’s the danger of splitting horizontal from vertical, you tend to forget some important things in the vertical domain to concentrate only on what the user will experience!
3. printing: this looked unreachable until iOs 4.2 was announced, but is not quite that out of reach now. I’ll definitely have a look into this for version 1.1 or 1.2, depending on the time it takes to implement and review the software.

We’ve just been through my initial thoughts about this app. A bit more planning is needed before we get into “real” business, ie. engineering stuff. I find it not only necessary, but really useful, to follow a process, even though I’m the only person concerned with this “project”. What I’m using to keep track of the progress is a 5-gated process, which derives from a manufacturing process I learnt years ago while interacting with Thomas Celluci, then COO of Zyvex, a Nanotech company. It is highly customizable and has proven to conform to most projects I carry out.

5 Gates to pass for a release

Here are the stages followed:

1. Stage One: Concept Feasibility and Evaluation

The goal of Stage One is to investigate new product opportunities. I start by looking at a particular application, research the scope of the product(s) that are required to meet the application, estimate the required resources, and then produce a Preliminary Product Plan. The first step of the Plan is to create a product description and a project overview to ensure that the product is aligned with our vision, core competencies, and the specific applications we’re targeting.

We define potential product attributes (features, benefits, reasons to buy), estimates market size in view of current market growth trends, and creates a preliminary product applications overview. We also put together a list of potential customers and competitors.

2. Stage Two: Planning and Specifications

The goal for this stage is to develop a complete set of marketing specifications (using the Preliminary Product Plan) and produce a Complete Product Plan (CPP). The CPP covers marketing opportunities, financial considerations, and the design concept. We also establish a “needs vs. wants” list, a development budget, source external resources, and a detailed schedule. We perform a SWOT-competitive analysis (strengths, weaknesses, opportunities, and threats), a scenario analysis, and a sales forecast estimate. We also check key IP disclosures if any.

Note: it is very important to make sure you are not going to use a private API at this stage. This will get you kicked out of the AppStore at submission.

3. Stage Three: Core Development

The goal for Stage Three is to complete design and development and to collect feedback on the product beta. We use the Complete Product Plan as the foundation for creating a design that meets the target specifications. We can worry only about dev at this stage, as the rest of the Marketing and Sales will be taken care of by the AppStore.

At this stage, we produce the core functionalities of the app. No programming ever took place before now, and it’s relieved that we, at last, get to open Xcode and peek at our development tasks. If need be, we revise the development schedule at this point.

4. Stage Four: Interface Development and Integration

The goal is to secure a high-confidence hand-off to the AppStore. I thought about splitting this stage in two, but in essence I’ve always kept it as is. The main reason is that I’m constantly switching between tasks at this point. I’ve got a working engine for the app, which means that it runs in the console. I now need to deal with the UI, and have found quite impractical to do so by considering the UI alone. Here are the tasks: * build an “ugly” UI, where all the elements are named, buttons are in place, and test all elements separately. I generally add elements one by one, together with their actions and link them to the core functions
* graphics: I realized years ago that I can’t draw, let alone create anything appealing to the eye. I’m lucky enough to have my own private graphics designer (Ivanna, my Wife), who ends up looking at the various pieces of design, and remains a critical assessor during the process
* build a logo when the app is finished. It’s easier to pick up some elements of your UI when your UI is here. * get it to work together… that’s the hard part! At stage four I concentrate only on getting the software running and performing as expected in the Simulator. There’s a general mop that comes up in next stage * prepare a webpage for the product, examples of use

Note: Now is the right time to read again Apple’s Human Interface Guidelines (HIG), if you want to make it past the review process (assuming your app performes as advertised).
Needless to say, I forgot to do so which wasted me one week at first submission for a really stupid item (interface rotation) - more about this in a coming post.

5. Final Stage: Build and Release

The goal of the final stage is to demonstrate product assembly according to QA standards, and deliver the product to the AppStore. This iterates between iTunesConnect and the Device. Basically, generate the signing certificates to transfer the software to your iPad, run tests and modify code until it runs like in the Simulator. Enlist some beta-testers and send them a copy, with extracts of the CPP to guide them in testing. That’s the final chance to change the product, and is of major importance! Last step, when everything’s good, is of course to submit to the AppStore.

This is what we do

Really, if you followed the first post (Part 1 below), we’ve almost completed Stages 1 and 2. We just need to put down a list of features and perform a needs vs. wants analysis. That’s key to getting into core development, and that’s what we’ll do in next Part.

So, we’re waiting for the release of Edito, our Markdown viewer/processor/integrator for iPad. We’ve had quite a large number of hits on the webpage we’ve put up, as well as a string of emails, so we’re hoping it will be released soon by Apple on the AppStore. I’m thinking about putting up a series of posts to tell you — the user — how Edito was developed, the whole genesis, and some of the pulleys and crowbars. I guess I’ll be missing some of the milestones I followed, but I’d rather try to put it on paper/screen while it’s still fresh in my mind. So, let’s get started. First thing first, who-what-why-whyme?

Existential questions

What

Let’s start with the “What” and “Why”. Pretty obvious, I was planning to buy an iPad, and looked for the apps that would best fit this new format. One of the things that I was interested in was a way to type documents on the go. In essence, I used to travel a lot, and my laptop, a MacBook Pro, although it gives me 4 good hours of battery life, was not enough for a transatlantic trip. Enters the iPad, with 10+ hours of battery life… in fact, way more, I happen to use it all day for work without recharging, I guess to get to 10 hours only you must run it for viewing movies or gaming - whatever. Anyway, among my needs, a good text processor comes top of the list. Looking over the app store, and googling “iPad Markdown” do not give any tangible result. Jumping to conclusion after a bit more research, there is no Markdown converter/viewer for iPad. Interesting?

Why

Why would that be? There are a string of possibilities, and I went through most of them I caught up 3 that were the most tangible:
1. it’s not easy to implement, so developers who have thought about it have either given up or not succeeded, or considered that the result was not worth the effort
2. you can’t use a script to carry out the conversion, so it’s one of those cases where we need to re-invent the wheel
3. there is no commercial interest for this kind of app…

Let’s start with number 3: I picked up on the web a nice review with stats about the spread between various types of apps in the App Store. Comes out that only 10-12% of app are filed as “Productivity” tools, while more than 80% of the Store is about gaming. Well, given the growth rate of the Store, and the number of devices sold every single month, there is a good potential user base. Even if you’re touching only 1% or 0.1% of the whole park of devices out there, that’s still a huge market.
Number 2, I did not think about straight, it came a bit later, when I was researching about Objective-C and iPhone/iPad programming. Comes out that it is impossible to use a perl script inside an app. On a Mac, not a problem, you define a NSAction and bang you’re done, but not on an iDevice. That’s a bad blow, because it means that you need to program an in-app converter, in C or Objective-C ideally. See, if this was not the case, I could have simply used John Gruber’s Perl script and be done in a breeze… but so would have other devs. Number 1, that’s a worry only when you get into the programming phase, and sweat over yet another freaking parser. Did I mention I hate parsers? Every developer of the planet must do too… Anyway, let’s get to the who-whyme and not be too afraid from all of that.

Who-WhyMe

My main problem here is not to develop or not to develop, it’s to evaluate if this is possible, and whether I’ll have time to go through it. I’m not a developer per se, by which I mean tha tI’m not a computer engineer. I’ve been trained as a Materials Scientist, and took a PhD in the same branch, in polymer physics. I’ve honestly loved it, and still do. Yet, I’ve got my own Company to run, and we’re involved in such a small niche that our distribution is not easy, although developing for these Nanotech processes is really interesting.
Anyway, I’m well trained in a dozen of languages, and since I’m away from the labs now I spend most of my time developing. My two languages of choice are Fortran (I think in Fortran) and Java (I speak in Java), and I mainly use a simple text editor for Fortran programming and Eclipse for Java. All the NIL Simulation Suite is programmed in Java by the way. Like any good scientist, I’ve also had to deal with C, Python and C++, although C++ has always confused me a bit.
Being a scientist can take various meanings, but for me it covers a few essential qualities: you must be patient, and very resilient. As I told my future boss when interviewing for my PhD position: when I bite a bone I don’t let it go. And most of all, you must not be discouraged easily, otherwise Research is going to be very hard for you, as you quickly learn that things are never over.
Armed with this, I can probably learn a new language, Objective-C, in two weeks to a month, and try to develop a parser for Markdown to HTML conversion. Cranky, but no big deal. And it comes at a good time in my personal/professional life: wife and kid on vacation, and I’m definitely getting tired of programming polymer physics, been on that nano-imprint problem for two years day and night, I need a break. It’s either that or programming a 3D Tetris or Rubik’s cube. Got to be honest though, I also researched the possibility to get a 3D visualization engine for Google Sketchup and other CAD formats up and running for this platform, but I’ve been having so many problems with converters/parsers of 3D geometries lately for the NSS that I decided to pause this. Really needed something else to distract me.

Conclusion

For me it’s a go. Buy a few books and read the intro chapters to see where we’re going in terms of technology and implementation. Get real, do a first plan of development and jolt down a few sketches to serve as a guide during the reading/assimilation and maybe development phase. Point is, I’ll be reading and learning selectively the advanced features of the language and the interface once I’m done with the basics of Objective-C. I’ll complete a few strategic points before going further, I’m still way way far from writing my first line of code!

Strategic inputs

As I said, I had a look for 1-2 hours at the business case, and it looked OK, although I could not pin some precise figures on how much the app would make. But it seems that selling such an app between 5 and $9 has potential. I did a quick SWOT analysis as well, which in general helps me to focus on the essential afterwards. I left all the fuzzy questions such as the definition of a mission statement (I don’t give a shit, that’s Corporate bull) and the implications of not achieving this strategy: I’m not trying to convince anyone but myself, and keep a few notes while I’m going through the creative process. So, simple SWOT with 2 bullets under each category:
1. Strengths: Markdown is really easy to use, and would make a perfect replacement for a rich-text word processor on the iPad. Dealing with text only files (ASCII) makes sense because of the very low memory and storage footprint envisaged;
2. Weaknesses: typing on the iPad, come on!? That’s a reduced keyboard, I can’t find the characters I need for Markdown in less than 3 strokes. Remember how Apple revolutionized the Music industry with the iPod? every single function was available in less than 2 strikes, which I still admire: the device was cool, but the software was a masterpiece in terms of usability. There are a few other weaknesses that could be mentioned, but I went for the fact that when I’m typing text in Markdown, I’m constantly switching between the app and the web-browser to gather links and pictures… which is not possible on the iPad. Well, it’s possible, but it means going out of the app and coming back after having copied a link, it’s not handy at all. And although the app’s got nothing to do with it, it’s still going to piss me off.
3. Opportunities: there’s no other app that is doing Markdown to HTML conversion out there! Tumblr is, in my mind, the best and easiest blog engine out there, and it takes Markdown text as an input…
4. Threats: any guys out there developing the same? Note to myself: keep Googling this entry along the process, check blog entries and discussions to identify key players. There are already a good number of text processors, they may come up with an innovative idea on how to do RTF in a way that complies with the device. Check what the (much admired) Omnigroup is doing, what Marco.org is up to, MarsEdit, the guys who do Coda and CSSEdit… basically keep up-to-date with all the big Guns: they’ve got the experience, the name and respect in the industry and among users - and they well deserve it. With 15 years of expertise in another field, you’re a newborn to this industry, don’t know the codes and rules, better be humble - another fresh start.

That’s all folks

Good way to start, we’re going to maximize our strengths, which are really those of the Markdown language, try minimize our weaknesses, achieve the opportunities and monitor the threats. Worse come to worse, someone else may come up with the same idea and do it better and faster than I, but I will at least have learnt a new language and system, and will be able to use it for something else (got other ideas relating to Engineering - exciting!).

That’s all for now, in the next post I’ll be scribbling on the blackboard my features requirement, which will lead to the development plan. What’s happening in between? Read everything you can, get to know what’s out there, read products reviews, look at interfaces, and get to understand the terms you’re not familiar with in the first chapters of those iPhone dev books.