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?
The American Dialect Society, which earlier this week named the term ‘app’ word of the year, has the following definition:
> The shortened slang term for a computer or smart phone application.
But Ian Bogost thinks it’s worth [thinking a bit more about](http://www.bogost.com/blog/what_is_an_app.shtml), and it is more than simply smaller functional units, a la the unix philosophy, with each one performing a specific task and that complex tasks require piping data through an array of applications:
> The app is a mixed blessing for computer aesthetics, just like music sampling is for music. On the one hand, we get many variations of the same thing that can surprise us when refashioned in different permutations. But on the other hand, we get fewer coherent, complete takes on things. And there’s a risk that deep meaning slowly seeps out of every unit as each does less and less. Apps and web services like Foursquare and Facebook give us a preview of this potential future agony, one in which the most basic chunk of meaning is the conveyance of a piece of data from a database to a screen and back again.
As I begin to assemble materials for my spring seminar surveying the digital humanities, I find myself trying to come up with categories, especially for describing arenas of activity. The digital humanities can be quite overwhelming when you are first introduced to them, and because everyone comes to them from so many backgrounds and with so many agendas, it’s hard to separate personal visions from something more synthetic.
Towards the latter, I am trying to think about how to describe some of the things that people regularly do, and I’ll be posting some of my initial thoughts in a series of posts that I will myself later synthesize into something like a syllabus and/or guide. Readers who want to follow along are welcome to do so. I am going to tag the posts with the number for the course, 531, and I will try to update earlier posts so that they turn up under that tag as well.
One of the first things to break out for me is the area of visualization, which is so important that it’s built into most network analysis applications. Visualization, especially dynamic visualization which allows you to adjust your view of the data in various ways, is an essential part of analysis and understanding.
Many of us are used to working with built-in visualizations toolkits like those found in Network Workbench or ORA or even Excel/Powerpoint — Numbers/Pages for those Mac users who eschew Microsoft’s productivity apps and OpenOffice users forgive me for not knowing the equivalents, but R also possesses some remarkable graphical abilities.
Up next: a comparison of the two.
It’s become something of a cliché that the iPad is for content consumption, leaving the business of content production to the “old-fashioned” general purpose PC. It turns out, if you leave matters to developers, they will come up with a lot of innovative ways for people to create content even with a fairly limited — in terms of processing power and memory — device like the iPad. Business Insider has a great write-up of a whole bunch of apps and uses that is worth checking out: go read it for yourself. I especially like the video for Studio Track — the video is not brilliant, but the app is.
I am about halfway through typing up my notes from the NEH Institute, and I am getting a little frustrated with my viewing options in my beloved OmniOutliner. And so I think to myself, “Self, you’ve just finished writing a decent-sized document in Pages. It now has an outline view. Why not try it out?”
And so I export an RTF from OmniOutliner — because Pages does not recognize OPML documents (and Word won’t either) — and open the RTF document in Pages. Okay, it kept the formatting but it doesn’t know what lines are headings, subheadings, etc. I can live with that.
What I can’t quite get my head around, however, is the sudden change in file size:
- OmniOutliner document: 12KB
- Exported RTF document: 25KB
- Resulting Pages document: 197KB
That’s an 800% increase over the RTF document and a whopping 1640% increase over the original file.
And for the sake of reference, the same file as a Word DOCX is 96KB.
Great googly moogly. I have to assume that both Word and Pages are inserting a whole bunch of infrastructure “just in case” it’s needed later. What all that is is not yet clear to me, but I hope to do some exploration in the next few days and I’ll get back to you on what I find.