I’m still thinking about creating an iOS app for field researchers. If I do, then I definitely want it to have a decent-looking icon. [Icon Resources](http://www.iconresource.net) offers a series of tutorials and materials that are useful — and the designer behind them has nice taste.
I must be getting old. I can’t find an e-mail link or any other route to offer feedback to the developer of an app of which I am very fond, [Day One](http://dayoneapp.com/). I tweeted the developer, but my tweet got picked up by a service of some kind and the developer came back mostly cranky.
In the mean time, here are my Day One app improvement suggestions:
* Give me a way to edit the style sheet for how my text appears.
* And then make sure my text also appears that way when it prints.
* Then give me a way to export more than one entry at a time: what if I want to print and bind a year’s worth of entries? No way to do that.
* And here’s my cool UI idea for the day: make it possible for a user to make their “inspirational” thought for the day be the post for that day from last year. Implementing that will make you a real leader in the journaling space.
I’ve written about Day One before, both in [comparison to MacJournal][mj] and as part of [how and why I blog][hw].
Sometimes the universe whispers in your ear when you are headed in the right direction. I have been thinking about developing an app for the iPhone which would be built for field researchers like myself, and then I came across this on [Kottke]: [Start Developing iOS Apps Today].
The folks at Rogue Amoeba have a [nice write-up] on the design process for the UI and icon of their latest application, [Piezo]. I’m bookmarking it because I’m thinking about trying my hand at iPhone application development: I want an app for my iPhone that lets me record in the field. They have apps that let you do this, but wouldn’t it be nice if the app also prompted you for some basic metadata or made metadata like GPS coordinates, easy?
Fraser Speirs has written a nice description of what makes an iOS ambitious, and he has a Google spreadsheet to back it up. (The link to the spreadsheet is at the bottom of the piece.)
When I am doing just about any kind of reading or film watching, I find that having my iPhone or iPad handy is really about having Wikipedia handy.
(If you haven’t donated yet, you should. Do it now. Give them $5. $10. It’s easy. I’ll wait. Really. No, really, I’ll wait. Go donate something.)
Occasionally I have my MacBook with me, and I actually find myself looking for the Wikipedia app that’s on my phone and tablet. Crazy, yes, but when you want to look something up quickly, it really is nice to go straight to where you want to go.
With that in mind, I would like to thank Andy Ihnatko for point out how easy it is to create desktop web apps in the latest iteration of the Mac OS, Lion. How easy?
1. Launch Automator.
2. Click on create a new App.
3. Find and drag the “Get Specified URLs” action into your workflow. (Just type the name into the search box until Automator finds it for you.)
4., Paste in the URL of the site you want to view.
5. Find and drag the “Website Popup” action into the workflow. Choose a size for the window.
6. Save. Done.
Here is what you get:
And it pops up this:
[AlertNotes for iPhone](http://www.alertnotesapp.com/). Great app with a really amazing/obvious idea: you write down the reminder the way you think about it and the app translates that into an alert. The only thing this thing is missing is speech recognition.
This video over at MSDN is great not only because it’s an interesting bit of history — and a moment when Jobs reveals his ability to see into the future and he’s doing it at a Microsoft event — but also because it’s a great explanation of how web applications work.
Design, Then Code is a nice place to begin thinking about making an app for iOS devices. The name is certainly good, in that it stresses thinking about the user experience in advance of building the code that creates the functionality, but the idea that one can do all the design work ahead of the construction is something that I thought we were long past. I understand that they are responding in some fashion to the sort of user experience nightmares that folks often point out as being the great weakness of Google’s application offerings, where there is a lot of functionality, you just can’t figure out how to get to it.
Why does it have to be one or the other? I thought we were beginning to figure out that it has to be both?