I've been ready and following the Stanford University class on iOS developement with iTunes U.app and started to build a reference called "My iOS Dev Bible" with Apple's iBooks Author. What a wonderful piece of software.
This electronic book will contain essential things about various subjects: Objective-C, Xcode, Interface Builder, UIKit, etc. I plan to make the book available for download as soon as the content is more than good enough.
After received a few but welcomed feedback, I spent some time redoing part of my tiles that will make up the board of pictures presented to the user. So here it is.
Here are a few designed tiles that would be presented to the user while browsing Tumblr's pictures. That was done with Sketch and Pixelmator.
The top right tile is a representation of browsing pictures from a specific Tumblr blog. The top right tile is shows a title without the metadata. The bottom left tile is an empty tile shown when the pictures are not loaded yet. And the bottom right tile is showing the metadata overlay.
How do you like this design? Post your comment to answer.
I'm constantly working on new versions of the application UI elements.
Last week Google announced that developers could start to respond directly to user's reviews in the Google Play store. When the news broke, I immediately tweeted something like "Hey Apple, are you listening?". Many of us complains about the lack of interaction between the users and the developers on the App Store. Personally I thought that instead of killing Ping (as the rumors goes), Apple could make it available to the App Store and allow people (developers and end-user) make the interaction there. But as Apple will probably kill Ping this fall with the next major release of iTunes and the tight integration of Twitter and Facebook in iOS 6, I seriously think that we'll have to wait. Then, I read this article from Matt Gemmell "Replying to user reviews" and changed my expectations from Apple. Here is why I think Google is wrong and Apple could be right.
The whole concept of publicly responding to someone's bad feelings (bad reviews) about your application is flawed because of two main things: emotion is involved and the process happens in a public place. The emotional part is all about a mad customer who just bought a 1.99$ piece of software and who think he paid 199.99$ and you the developer who spend nine months of your life working and shipping an application that maybe not ready for prime time. How do you expect the developer will respond? Defensively. The other part of problem is the fact that publicly we don't behave the same way as in private. Maybe the customer will post a really bad review in order to make other potential buyers stop thinking about buying the same piece of s*** he or she just bought. The whole idea of allowing the developer to step in and respond calls for trouble and a lot of waste of time. The problem is with the review system and Apple can improve the process very simply.
Apple should make the following improvements to the App Store:
- make the Support link more prominent on the application's App Store page.
- invite the user to visit the developer's web site and seek for support before writing a bad review. This could happen right in the write a review process by presenting a reminder at the beginning of the process.
- allow the developer to respond privately to a public review by sending the respond to the user's Apple ID's email.
- improve the notion of flagged reviews and review's usefulness in order to help others make their own decisions before posting a really bad review.
As you can see, there is room for improvements in the App Store review system. Let see how Apple will move forward with announced stores redesigns this fall with iOS 6.
These days I'm working on the main screen of my Tumblr photo browser. I'm delighted by Sketch and Pixelmator. I'm using Sketch to the general screen layout and when I'm not able to create an object with it, I'm using Pixelmator and this does the trick.
I think of application design when I'm drawing screens. I feel I design an application when I'm thinking about what will be part of the Model, what will be part of the Controller and what Views will be required in order to display things to the users. I'm designing an application when I start to list the open source modules and framework that will be needed in order to save development time. I'm designing an application when I start to look for application icons. I'm building an iPhone application when I'm building the list of features that will be part of the initial release and all the subsequent releases. Yes, I feel that I'm into something when and I'm looking back into previous WWDC videos I order to remember how to write code.
The more I look into WWDC 2012 videos and the more I think about my Tumblr Photo browser application development, I think I might start with iOS 6 as the minimum iOS requirement. There are so many new APIs and Xcode new features directly related to making developer's life easier. By the time I finish working on release 1.0, I suspect there will be more iOS 6 than any other iOS versions.
I'm still planning the features of my Tumblr Photo browser that I'll develop and sell on the App Store. The process of planning the application's features set is important. First, it will help me prioritize my development efforts. Second, I'm sure many features will be interesting to include but a few will be left out altogether or will be part of a subsequent release.
What features goes into 1.0 release? What features are essential to include from day one? Answering these questions is like asking myself: what is the essence of my application and this is critical. Features less important will be part of subsequent releases but I'm still think about them now because it may influence the design of the application, its behaviour and the visual look and placement of user interface elements. It is like thinking about application behavioural extensibility.
Right now I'm using Remember The Milk service to help me write down the application features and classify them in application releases. For this task, I created three to do lists the following way:
MyApp 1.0 feature set
MyApp 1.1 feature set
MyApp 1.2 feature set
For each feature, I put them in the correct release. When describing the features, I find myself pushing further the inclusion of certain features in a subsquent version if I feel the features will take too much time to include in the prior release or if it is not that important to the application.
As you can see, thinking about a mobile application (or any application for that matter) involves many things, not just coding and Photoshopping application's visual elements.