I was watching a recent episode of Anthony Bourdain's: No Reservations on the Travel Channel this morning, and came up with an idea for an application.
Bourdain described the process in which orders are conveyed through a restaurant: customer tells waiter, waiter writes on order slip, waiter goes to waiter station and inputs order into terminal, order gets directed to the appropriate kitchen personnel. I was struck by how the input terminal involved bringing up a diagram of the appropriate table, and inputting the order for each chair around the circle. This seemed something easily transferable to an iPod Touch style interface.
I'm imagining a situation where the customer tells the waiter, the waiter touches on the table in a map of the restaurant, touches on the seat, is given a series of menu choices corresponding to things on the menu, touches complete, and the order is sent directly to the kitchen. Maybe the customer orders shrimp and the kitchen just ran out of shrimp, the software would show an alert.
In this scenario, the waiter only has to enter the data once, there is less chance of transcription errors, the restaurant does not have to set aside valuable floor space for the waiter station, and status information is more current. Presumably, the people best positioned to make such software is whoever makes the current restaurant terminals, but some enterprising types could get into the business right now while the going is good, by providing an entire Mac/iPod based solution which incorporated the whole system: data entry, accounting, kitchen display screens, etc. If anyone uses this idea, cash is always an appropriate gift.
It would be nice if Apple were to come up with an industrial version of the iPod Touch that was not worth stealing as a media player for specialized situations like this.
Monday, March 17, 2008
Wednesday, March 12, 2008
The iPhone and the End of Bloatware
You still see tables filling full page ads in computer magazines, a column of checks for the product being advertised, a column of blanks under the competitors. This was the game of the big company, the Microsofts of the world; organizations with large enough staffs to code solutions to any need or perceived need of any customer big or small. Every customer needs 10% of Microsoft Office, but every customer needs a different 10%. Smaller, more nimble companies have made better pure word processors, but they have all been relegated to niche markets, as the vast majority of customers know that somewhere in Office are the exact features they need, plus a bunch of features they might need someday for free. It's just a matter of finding them. And in a world of full keyboards, contextual menus, 24" monitors, gigabytes of RAM, terabytes of storage, multi-cores, and fast CPUs, there's always somewhere to tuck a feature.
Now comes the iPhone/iPod Touch with its 480x320 screen, no keyboard shortcuts, finite memory and demand for near instantaneous launch and quit times. Ponder this small subset of toolbars for Word 2003 on Windows:
and imagine that each icon was twice as big to accomodate the stubby adult forefinger. Imagine making even this small subset of functionality accessible somehow while still showing content. I've a good imagination, but it fails me here.
Anti-bloat features of the iPhone OS:
No, what we will get are mini-apps. Apps a single competent programmer will bang out and polish in 3 months or less. The functionality which makes up Office could be broken up into scores of such mini-apps: a mini-table creator, a mini-slide presenter,a separate mini-slide editor, a database client, a little drawing app. In fact, even these small apps will probably be too big, and will be streamlined for more specific task oriented, specialized purposes: a blog post word processor, a series of charting modules which each do one type of chart, a specialized Keynote which only has the tools needed to create presentations following a single corporations style—imagine all those exactly the same style presentations you see at Apple events. That would be doable on an app which could only show 5 toolbar icons at once, and which relied upon gestures, animation, templates and transparency to maximize what the user can see and do. And, lots of apps to help with one's location based social networking, whatever that is.
In the iPhone ecosystem, bloatware is non-adaptive. The big have no feature advantage over the small.
The experienced Cocoa programmer does have an advantage, however. I have been reading through the Apple example code, and it is made up of delightful exercises in object oriented minimalism. Actual, full blown apps written in this style will be incredibly light weight for the functionality delivered, with zippy launch times, and responsive interfaces. This seems to be how one masters a framework, and it is especially true of Cocoa, by learning how to do the most with the least code, which is again, the anti-thesis of the bloatware mentality, which seems to only care about churning as much code out as possible.
Now comes the iPhone/iPod Touch with its 480x320 screen, no keyboard shortcuts, finite memory and demand for near instantaneous launch and quit times. Ponder this small subset of toolbars for Word 2003 on Windows:
and imagine that each icon was twice as big to accomodate the stubby adult forefinger. Imagine making even this small subset of functionality accessible somehow while still showing content. I've a good imagination, but it fails me here.
Anti-bloat features of the iPhone OS:
- Apps must launch quickly (in practice anything less than a second will seem intolerable), and quit as fast or faster
- Apps must be relaunched every time you move back from another app.
- There is a practical limit of 10 or so toolbar type icons per view, and 5 is more reasonable. This leads to a geometric decrease in accessible functionality versus a program on a PC. If you can fit 40 toolbar icons on your computer's monitor, and each opens a dialog with 40 items, and each dialog item invokes a subdialog with 40 features you have 40x40x40-40-40=63,920 accessible features versus 5x5x5-5-5=115 features 3 levels deep on an iPhone (well you could probably fit more than 5 items per view, but you get the idea)
- There are no contextual menus, much less multi-level contextual menu trees
- There are no keyboard shortcuts, eliminating the need for laminated keyboard shortcut hint sheets Scotch taped to the back of the iPhone
- There are gestures, but really, how many unique gestures can you expect a person to master: pinch, shake...?
- There is a finite amount of RAM, and telling the user to "just add more" is not an option
- Lack of both RAM and application interaction are a firewall against the metastasized bloatware which are "Office Suites," which have to at least pretend to work together
No, what we will get are mini-apps. Apps a single competent programmer will bang out and polish in 3 months or less. The functionality which makes up Office could be broken up into scores of such mini-apps: a mini-table creator, a mini-slide presenter,a separate mini-slide editor, a database client, a little drawing app. In fact, even these small apps will probably be too big, and will be streamlined for more specific task oriented, specialized purposes: a blog post word processor, a series of charting modules which each do one type of chart, a specialized Keynote which only has the tools needed to create presentations following a single corporations style—imagine all those exactly the same style presentations you see at Apple events. That would be doable on an app which could only show 5 toolbar icons at once, and which relied upon gestures, animation, templates and transparency to maximize what the user can see and do. And, lots of apps to help with one's location based social networking, whatever that is.
In the iPhone ecosystem, bloatware is non-adaptive. The big have no feature advantage over the small.
The experienced Cocoa programmer does have an advantage, however. I have been reading through the Apple example code, and it is made up of delightful exercises in object oriented minimalism. Actual, full blown apps written in this style will be incredibly light weight for the functionality delivered, with zippy launch times, and responsive interfaces. This seems to be how one masters a framework, and it is especially true of Cocoa, by learning how to do the most with the least code, which is again, the anti-thesis of the bloatware mentality, which seems to only care about churning as much code out as possible.
Friday, March 07, 2008
Re-imagining a Desktop Utility into Cocoa Touch
If anybody's starting up a business based around iPhone development, and need a chief engineer, I'm sure you can find my e-mail address.
Well the momentous day came, and the iPhone SDK is in our hands. I wish I were not so incredibly busy at my day job, or I would take a couple weeks off and learn the ins and outs. But, I've decided I should start small and port a little application I wrote, Remote Remote GH for MythTV, which I'm afraid I have not been properly maintaining, but has the advantage that it would be much more useful on an iPhone than on a laptop, and it only uses Cocoa and various Core Foundation routines. I'm going to go through the exercise here of paring the interface down to size and making it more in touch with the Touch's way of doing things. Then sometime in the next couple months, I'll take the time to actually do it.
Let's look at the original and see how we can get it down to 320x460 and 480x300 (which are about the available sizes once you discount the "status bar" region of the display). Not only do you have a smallish screen, there is inconvenient text entry, and any widget on screen should be at least 44x44 pixels to deal with the stubby fingers of adult humans. On the plus side, there is multi-touch and 3D movement via the accelerometer.
As I said, I have very little time on hand, but I was able to make a first step of compiling my network protocol classes, which compiled after a mere 5 code changes—removing #include "Cocoa/Cocoa.h", and replacing call to Carbon's NewPtr(...)/DisposePtr(...) with malloc(...)/free(...).
Then it was just a copy/paste job to make a stripped down version of my original application delegate, which just stuffed replies from the server into a simple UILabel in my main window. Amazingly, this worked on the second try, with a connection forming with the server, followed by periodic requests for status. If anything, the networking code is more solid than in the desktop application.
I'll update this later, as I start to build the GUI, and figure out how best to minimize my power usage (keeping the Wi-Fi unit off for extended periods).
Well the momentous day came, and the iPhone SDK is in our hands. I wish I were not so incredibly busy at my day job, or I would take a couple weeks off and learn the ins and outs. But, I've decided I should start small and port a little application I wrote, Remote Remote GH for MythTV, which I'm afraid I have not been properly maintaining, but has the advantage that it would be much more useful on an iPhone than on a laptop, and it only uses Cocoa and various Core Foundation routines. I'm going to go through the exercise here of paring the interface down to size and making it more in touch with the Touch's way of doing things. Then sometime in the next couple months, I'll take the time to actually do it.
Let's look at the original and see how we can get it down to 320x460 and 480x300 (which are about the available sizes once you discount the "status bar" region of the display). Not only do you have a smallish screen, there is inconvenient text entry, and any widget on screen should be at least 44x44 pixels to deal with the stubby fingers of adult humans. On the plus side, there is multi-touch and 3D movement via the accelerometer.
- Disconnect/Connect Button This should probably be done away with entirely, and the app should try to keep a connection up when visible.
- Show Keys Button This brings up a list of keyboard keys which are appropriate for the current state of the MythTV. The idea was for the user to control the MythTV with the same key presses used when sitting in front of the computer running the MythTV frontend. Keyboard input on the iPhone being discouraged, replacement with a series of contextually appropriate button panels is appropriate. (A panel for watching recordings, a panel for navigating, a panel for DVDs, etc.)
- Scrolling Status Console This was a area devoted to telling the user what has happened. This can be condensed into a 2 line status widget at the bottom of each screen.
- Navigation Buttons Live TV, DVD, etc., can be put into a standard navigation bar, to allow the user to jump to a common task, which I will pare to Live TV, Recordings and Video
- Recorded Programs Table This can be moved to its own panel, and condensed, with perhaps a sub-panel which the user can navigate to with more complete information for each recorded program.
- Big Scrub Bar I like the idea of making very long scrub bars to allow for fine control over where in a program the user can jump. This is a good candidate for a control which is always along the long axis regardless of the orientation of the device, and will only be visible in play back mode panels.
As I said, I have very little time on hand, but I was able to make a first step of compiling my network protocol classes, which compiled after a mere 5 code changes—removing #include "Cocoa/Cocoa.h", and replacing call to Carbon's NewPtr(...)/DisposePtr(...) with malloc(...)/free(...).
Then it was just a copy/paste job to make a stripped down version of my original application delegate, which just stuffed replies from the server into a simple UILabel in my main window. Amazingly, this worked on the second try, with a connection forming with the server, followed by periodic requests for status. If anything, the networking code is more solid than in the desktop application.
I'll update this later, as I start to build the GUI, and figure out how best to minimize my power usage (keeping the Wi-Fi unit off for extended periods).
Monday, March 03, 2008
On the Badness of Skins
I refer you to this posting on the product forum for the CoreAVC player application. An application which claims to have extremely efficient H.264 decoding.
Here is the company representative explaining why the Edit menu always comes first , instead of the File menu as Jobs intended it.
CoreUI, our skin layer, is not meant to hardcode things like "File". There are some apps that don't deal with any file and still require text editing. And we can't wild guess where they want the Edit menu. The thing we could do is add a special
Now, I would very much like to see better efficiency in H.264 playback, especially on the 1.6 GHz Core Duo Mac Mini on my wife's desk. That would be a good thing. But here is a cross-platform application whose creators can't be bothered to put together a simple Cocoa shell application for their player, and believe me this would not be a lot of work for a semi-competent Mac guy to throw together. Instead, they've ported their skinning engine—which I'm sure they are quite proud of. The engine is extremely flexible, except in the sense that you can't put together a skin which doesn't make their programmers look clueless.
Let's see. How much time to put together a nice Cocoa application to host your player: X. How much time to port, and debug a "flexible" skinning engine: maybe 4X. So, precious development time which could be spent elsewhere is instead spent on skinning: a misfeature given to the world by WinAmp, and repeated by seemingly every other media player intent on letting skinless iTunes eat their lunch.
You want to know a big reason WinAmp, or MusicMatch (which I worked for) or whatever, couldn't keep up with Apple's iTune team? A big reason was skins, if you are spending 30% of your development time maintaining skins and the skins engine, and you start rejecting new features because they don't fit into the design of the engine, or because you have to add new artwork to 10 separate skins, and you have your best minds trying to figure out an abstract design for docking arbitrary subwindows, and your testing staff spends all day long looking at every permutation of new feature and skin, then it's going to be like you are fighting Apple with your arm tied to your leg, and your leg is bolted to the floor.
And for what? A feature that the vast majority of your user base is at most going to flip through once and forget exists.
BTW, CorePlayer, at the moment, is virtually useless on the Mac, as it lacks AC3 passthrough. You know an actual feature involving playing media. Maybe, if they hadn't spent all that time on their skinning engine, they'd have a product Mac users, like me, would like to buy.
Here is the company representative explaining why the Edit menu always comes first , instead of the File menu as Jobs intended it.
CoreUI, our skin layer, is not meant to hardcode things like "File". There are some apps that don't deal with any file and still require text editing. And we can't wild guess where they want the Edit menu. The thing we could do is add a special
Now, I would very much like to see better efficiency in H.264 playback, especially on the 1.6 GHz Core Duo Mac Mini on my wife's desk. That would be a good thing. But here is a cross-platform application whose creators can't be bothered to put together a simple Cocoa shell application for their player, and believe me this would not be a lot of work for a semi-competent Mac guy to throw together. Instead, they've ported their skinning engine—which I'm sure they are quite proud of. The engine is extremely flexible, except in the sense that you can't put together a skin which doesn't make their programmers look clueless.
Let's see. How much time to put together a nice Cocoa application to host your player: X. How much time to port, and debug a "flexible" skinning engine: maybe 4X. So, precious development time which could be spent elsewhere is instead spent on skinning: a misfeature given to the world by WinAmp, and repeated by seemingly every other media player intent on letting skinless iTunes eat their lunch.
You want to know a big reason WinAmp, or MusicMatch (which I worked for) or whatever, couldn't keep up with Apple's iTune team? A big reason was skins, if you are spending 30% of your development time maintaining skins and the skins engine, and you start rejecting new features because they don't fit into the design of the engine, or because you have to add new artwork to 10 separate skins, and you have your best minds trying to figure out an abstract design for docking arbitrary subwindows, and your testing staff spends all day long looking at every permutation of new feature and skin, then it's going to be like you are fighting Apple with your arm tied to your leg, and your leg is bolted to the floor.
And for what? A feature that the vast majority of your user base is at most going to flip through once and forget exists.
BTW, CorePlayer, at the moment, is virtually useless on the Mac, as it lacks AC3 passthrough. You know an actual feature involving playing media. Maybe, if they hadn't spent all that time on their skinning engine, they'd have a product Mac users, like me, would like to buy.
Subscribe to:
Posts (Atom)