Showing posts with label Mobile App design. Show all posts
Showing posts with label Mobile App design. Show all posts

Wednesday, 11 February 2015

iPhone Killer Apps - Warhol

Its been a while since the Carnegie Museum released the original Warhol DIY app. As a fan of the digitalisation of modern art I immediately downloaded it and... well, found It was harder than expected. having developed my own film and photos back in the day, and decided it hard work, I also did silkscreening, and found that even harder work, so I do not know why I was expecting the app that does the even more difficult Warhol silkscreen process to be easy, but I did, like we all expect to buy an iPad and do a Hockney by downloading brushes app....  The truth is, its not all that hard, after a think you remember that, like all good photography and art, it all starts with understanding light... to get a good digital silkscreen print you need to shoot the right image to start with, and this is hard, if not impossible on a mobile with no exposure control. So you search through your images for the right exposure, there are not that many, and the ones that are do not have the right subject...
The only usable image from original app, this will now change!
It all seemed like hard work and I only found one image that I could sort of use originally, and even then the result was, well, it did not get shared, let's put it that way!. So, for example, if I wanted to use this iconic Lotus, a brand made famous from the 60's and use its namesake bright yellow Warhol used so much on his screens, there was no much I could do: a black car in a dark street was just not going to work. It also was a pain to edit, I had to use another app to crop the photo (pre iOs 5 camera crop feature) rather than in app. These have both been addressed, as well as another key issue I will get to in a minute.
Editing and cropping in app is an essential addition
So, when the last update came out with exposure control I picked up from where I started: Crop photo instagram style in app - check; 
exposure levels mean you chose the subject you want
Edit the exposure level in app - check... we are now on our way! the next problem, and the reason I left the darkroom work to others, was the trial an error process... before the app was unforgiving of mistakes, and made you start again, it now let's you go back and change exposure levels etc.
fine tuning exposure now does not mean starting again
The only issue I still do have is that I was never good at the underpainting with a brush, on the screen that does not get any better, but to be honest, I am more of a fan of the bass relief style single silkscreen colouring with no underpainting... which is just as well. I have not tried it on a tablet yet, but undepainting on a screen, even one as good as the iPhone's, is not great. So what are the results like? Well, I am still playing with the exposure but will let you know :)

There are also sections explaining the process and a bit more about the museum, etc, so all in all is a great app and well worth paying for.

Sunday, 24 March 2013

climate clock killer app weather apps

I have ended up doing a lot of work on weather apps over the years, and a lot of work on UE of apps to either make them better, unique, luxury, worthy of a product launch, etc.

So I was very excited to come across climate clock for a few reasons, firstly because it brings together two key recurring themes of mine;weather apps and app user design, but also as it marks the beginning of a new period on app design as far as I am concerned.
Climate Clock is a unnecessarily beautiful by design - finally we have apps like this! 
So why is this app so important? Well, I started life in consulting as an e-commerce consultant, and watched and analysed the web from dreadful days of active gif ridden sites to the responsive web we have today, and in between there were some design treats and progresses that made my life, and those who consume the web... well, better.

A quick example, to show you where i am going, was the Jackson Pollock page of a good few many years ago, but there gave been more from pixel mosaics, to pixel art and more.
Hours of fun can be had at which caused a stir in its day
Climate Clock is the first app I have come across that you will just open for the sake of it, with no need for the time nor the weather, just to see the background and its progress... which is a huge development in apps. yes, there are beautiful apps out there, from path to even functional apps like Relais & Châteaux, but this is different, this is design in technology because we can... and life is just not worth living if people do not sometimes do things great and do great things just because they can!

Back to the app as an app, its actually not that useful at telling the weather over time in the main screen, however, swipe from the bottom and the most useful omission from most weather apps appears: a ten day forecast.
10 day forecast within the context of the main screen make the app very useful as well
I know and appreciate the amount of thought that has gone into this app - I and a UE designer spent 200 hours getting the first, now omnipresent three day weather button for active views for the Accuweather app for a showcase handset launch, and that was just an active icon!
200 hours work!
From there there is not that much to write home about - there is the usual gesture to go from location to location, however then there are clever but not intuitive other gestures to edit locations, which had me screaming at the app at first. fortunately, the app is pretty enough to get away with it and reveals a pretty, dare I say, Metro-esque settings page.
did anyone see a Metro UX guideline document handing around anywhere??? :-D
... and yes, my life is so glamorous I need to know the weather in Reading... don't ask...

So there we have it, combine a clock and weather and you have a killer app, and well worth spending 69 finest British pence on. If only now we could edit the Apple home screen on iPhone and iPad to have the weather app we want, instead of the abomination that now is the native iPhone weather app (no, its not 2007 any more Apple...) or the lack of weather that iPad owners are deemed to have... you could even edit the homescreen apps on Symbian, let alone iPhone modern day competitors.. and yes, that does include Windows Phone!

Thursday, 15 November 2012

Why iphone 5 apps updated so late?

Slow iPhone 5 app updates

There has been some talk on the world wide gossip web lately that the iPad mini is the beginning of the demise of Apple... obviously there was a band of Apple lovers who took grave offence and blocked sites for saying so on their iRouter, and the other band of iHaters relished the idea...

iPhone 5 beginning of Decline of Apple?

I personally sit in the middle and think it would be a great shame if it were the beginning of the decline, however it did get me thinking more about a casual observation that I have been capturing in screenshots on my iPhone 5 post release; I have noticed that that is the lag in the updates from the major app vendors, longer than iPad 3 (or new iPad) which does make me think Apple is either relaxing or loosing its grip (depending on how most people seem to be able to only look at these Apple issues) or; if we are lucky - that the app environment is finally maturing!
Major apps like Spotify are only just adding iPhone 5 support to their apps

iPhone5 developer roadmap maturity?

So why can this be? Well let's explore the "is it maturing" side first: proper development has a roadmap and cycles, that is; you have a roadmap of what you want to do over the next 6 - 18 months depending on many factors such as size of company, and then monthly or quarterly cycles when these features are added in priority. Unfortunately in app world this has not happened, and to be honest, UE has been impacted as a result. I only have to look as late as the beginning of this year at my Mobile Monday London event digest to see that developers in app world are still running round prioritising customer feedback features over launching new platforms, and adding them in what seems like an ad-hoc manner. Therefore, possibly, hopefully, this is a a sign that the market is maturing and the iPhone 5 new screen size is being put into the next available cycle on the roadmap rather than developers running round like headless chickens for the new ifeature as soon as they can?
4 to 5 days post iPhone 5, a major app release update does not include iPhone 5 support
Further evidence of this maturity could be seen in the shape of the native Google app for iPhone5 taking longer than anybody would have expected to go into the app store after the launch of the iphone 5 and iOS 6 with the dreadful downgrade to maps widely reported would have led to the app being in the store "yesterday" in previous times. So let's move on to:

iPhone Android app roadmap maturity is here!

The other way to look at this is that its the beginning of the decline of Apple and Steve Jobs would have not let this happen! I hope it is not, for many reasons, as Apple has pushed apps, app stores, UE and devices in the last few years further than the entire mobile industry managed beforehand (am not counting Siri in this equation)... However the fact still remains that key apps ar taking time to adapt and some could argue its sloppy management of app stores. It should also be noted people have recently moved jobs in Apple post the iPhone 5 launch: when launching a new device with a major change such as screen size and performance improvement; you do need to look at your ecosystem and identify the apps and app developers that you need to take aside and say in confidence: can I have your apps ready for the launch of my new, and let's add in here, well overdue... iPhone 5. As a user I was left seeing my bigger screen going to waste with apps I would expect to be up the in the wish list. I will also hasten to add, that this has not been during a period of low activity; I have been installing app updates almost daily since the iPhone 5 since release.

For now, I am taking thee high road and seeing it as emerging maturity in app land!

Friday, 18 May 2012

New G+ App for iPhone

So Google+ finally gets some love and gets and update that brings it into killer app territory.... and it has made it into the iPhone killer apps list as well as the Android killer apps list this was much needed, as in a report on my MVNO blog on Facebook activity being mainly mobile and the Mobile App store blog on even low end phones now getting Facebook integration: mobile social is now big business, in case you still had not heard!

So, without a decent app, Google+ may have been missing a trick for a while. yes, the tech savvy will create a shortcut to their homescreen, but this does not give you notifications (see my native vs. html5 debate for more on this) and for many people you still need "an app for that".

So what is all the fuss about?

Well firstly, it looks good. There is no denying, clean simple design is what Path, Flipboard and pulse have been soaring in popularity on, and this app now has it...

Secondly, it gets it... for a while I have seen posts on the point that Facebook photo implementation on the web is awful: Its true, while Facebook generally have great UE, the images are handled in a very "we installed this 3rd party tool" way; and the mobile app (with the exception of the windows Facebook app version with its panoramic view) did not show off photos as well as they could either. Even The Sun newspaper caught onto this a few decades ago: many people just look at pictures, especially if the content was written mostly by chimps, a point which both Facebook and The Sun newspaper largely share (sorry, could not resist, but at least Facebook has the excuse that its UGC (User Generated Content))

So yes, boys and girls, if you got pictures, show 'em off, and that is what Google+ app has done very well.

People living in UK will be able to pinpoint which day this was in the whole year :)
Here is my colleague Keith getting some inspiration, on one of the few days when a) there was sunshine and b) the lawn was actually mowed :) In fact, Google+ got it so right, that a certain other social network soon followed:
I wonder where Facebook got the inspiration for this "wide photo" update???
It would not be fair at this point if I did not point out that the Google+ app widescreen images, with subset picture of the poster, does not have influences from timeline on the web, its just amazing that these days, with articles like at the top of the page showing mobile has surpassed the web in terms of interface to all things social, that the apps are so neglected - but then I have always argued, that nothing makes a business take its eyes off the ball like having to pander to (still potential) investors...

if you want notifying when more articles like this come out, my Google+ and my company, Virtuser's Google+ or like Virtuser on Facebook for updates

Monday, 6 February 2012

Killer Apps Ecosystem

I have just updated the section on killer apps in general, as a) I read a good quote that gelled some thoughts on it, and b) had a discussion with a colleague in the industry that got me thinking, as well as the fact that I have as much more work in 2011 on SMS and HTML5 than on apps in 2009 and 2010...

Friday, 3 February 2012

HTML5 vs. Native app development

The HTML 5 vs Native debate was raging yesterday in the Mobile Monday London event (see my digest on this blog) and will continue to for a long time, just as the java vs. native did and the widget vs. native did, and just as much as the "which OS choice/debate" I discuss here in my blog as well

The reality is blurring with recent announcements of high profile games on HTML5 like cut the rope however the issues that I found when heading up the iPhone porting for Voda 360, the first major W3C HTML with APIs if not HTML5 still remain even with these successes.

Then I go out into the market and hear some game developers doing cross platform, some adopting HTML and other focusing on the multiple approach of iOS and Android, looking at HTML5 to cover the rest. That is with games at least, and will be the case of many apps with access to low level functions and APIs (beyond GPS, audio, video, etc).

With certain apps it is much clearer:  I spoke to a developer of a major social network that was launched recently who said they would never have gone native if they did it over again: the user experience is just two fragmented between the web, tablets and the main app OSs and then mobile web. I also know users who have ditched native apps for social networks in favour of the HTML5 experience: quicker, closer to the web, the same on tablet as smartphone and the closet to their web experience... and as a result I specified a social network for a client recently in html5 with native in potential roadmap...

Then there are the mobile operator clients considering portals and app store, more relevant to my portal blog, but still very interesting for the case in hand: Its important to maintain flexibility in these situations, and fix your roadmap (in scope) only for one or at most two quarters ahead. Just recently, for example, a mobile operator client was faced with a situation where their development on an app store/portal was lead natively on two platforms with another two following and another two in roadmap... when Microsoft announced that W7 was going to be a closed environment, symbian split, meego was sidelined and RIM became evidently more fragmented (bb5 vs bb6 vs bb7, etc) then the option was very clearly android plus... native or java or HTML5. It was still a little early then, but the answer would be much clearer today.

So, with so much depending on what you are doing where and with whom... and so much social, regional and international fragmentation, however there are some key considerations to take into account:
  1. what device is it running on? which will affect many things, but in short, running in  a sandbox without native extensions will be slower on things like
  2. refresh rate: while low end Java devices and even proprietary runtimes like Offscreen Media's were running 50-100 frames per second, the first web runtimes were at 3-5, with the best developers on best devices eeking out 10-15. Even if you get this much higher, its still a limiting factor over native, and those pushing the boundaries will always prefer native
  3. how many platforms are you going to distribute on. Its all very very well having a cross platform app and cross platform intentions, but do you have the time and resources to update APIs across 20 stores, check 100's devices, upload across many platforms, have the project management and roadmap skills to manage the process, etc, etc.
  4. What is your target audience now and later. if you are going after advanced users and then mass market then native first, html5 later maybe an option, if revered, then reversed, obviously. if you have a product like Sonos, why go to the extra effort of making the platform universal when all your customers will have at least one android or iOS phone or tablet at their disposal?
  5. What regions are you looking at? HTML5 will play better to strong growths in ever cheaper smartphones, like Africa, vs those with a solid smartphone base (Nokia in parts of Asia and Latam, others varied in US, Europe and ROW)
  6. Do the stores you are planning to roll-out on have the features and APIs you want? There is no point creating your freemium app that requires in-app upgrades or subscriptions in HTML5 for flexibility if it would have been quicker to do it natively in the two stores that support what you want to do, and the ad serving and other APIs are completely different in each deployment
  7. Do you want to be off-line?
  8. Do you want to obfuscate and/or only have certain functionality using server based algorithms for extra security.
Its interesting times, I shall be updating this article as more interactions with clients and colleagues provide more scenarios, and will announce those changes here at my Google+ and my company, Virtuser's Google+

Tuesday, 24 January 2012

Mobile App OS choices

When deciding what OS to go out on there on are a number of factors to take into account, unfortunately, as with most things apps, all most people is see is numbers. Numbers are important, if you want distribution, but it is also important to look at the product, who uses it and its fit.

Bloomberg, for example, an app I have helped port to different OSs, is a great fit for Blackberry, Nokia and iPhone as the key business phones in the key Bloomberg markets: finance. While it may be good to be everywhere, you have to ask the cost of that and the incremental gains. Moreover is managing all these versions - they may be within budget to build, but as new services are rolled out, managing a roadmap across lots of mobile OS and their subsets (BB6, BB7, ipad, 3G and 4G screen sizes, etc) can become costly and difficult to manage.

Spotify is on Meego and the Nokia N9, as well as iOS and Android, but not on windows market; why - well the N9 has hit a sweetspot and will ship around the world to the kind of audience who will pay for a premium service, and the are relatively few apps on the device. Sonos is just on iOS and Android, probably based on the premise that while its users have other devices, if you have a premium music device, you will have either a tablet with the aforementioned OSs or a dedicated controller.

Social networks want to be pervasive, however with each OS version comes fragmentation, then there is the issue of prioritising the versions when you update an API and risk offending part of your base: the only option is to update all at the same time or plan very, very carefully and risk backlash! An developer from a social network recently told me that if they did it all again they would do probably just one or two native apps (no prize for guessing which ones) and the rest in HTML5 - he then corrected and said - no, I would do them all in HTML5 and have done: after all you get the most important APIs: location, audio and video, working out of the box, across all devices, in one go. How important is this, well very;
  1. one it means you can stay on or ahead of the curve - rolling out new services on mobile almost or even in parallel
  2. it means you avoid embarrassing issues like the iOS facebook app that recently had everybody in London posting from Walton Abbey for a while
  3. moreover, fragmentation is minimal: another developer recently expressed that his users have upto four different experiences of their product: one on a tablet at home, another on a PC at work, and then another one or two on their work and personal mobiles
A weather app, like accuweather for example will have different priorities, from bums on seats to strategic deals, which will see them having everything from bespoke versions just for the Nokia N97 and Voda 360 homescreens (yep I did that, it seems to be everywhere now, from samsung in store ads to tablet online promos - which is great) to then being on maybe android more than iOS now (how many weather apps must there be on the App store!).

So, in short there are many things to consider:
  1. What APIs if any you need and which support them and which handsets. Apple is still all inclusive (all devices have a compass, gps, etc, etc) however other devices / OS have all sorts of fragmentation 
  2. how easy is it to integrate the service you want on that platform and which platform(s) Android is not too far from Java J2ME, you may want to focus on this from the beginning
  3. How much is your app, how important are ads vs. revenue, freemium support
  4. do you have the need for fancy functionality such as in app subscription, upgrade, etc.. your mileage WILL vary by OS
  5. How important is design and brand. Apple are very aware of the style, UX, fonts, etc and encourage homogeneity with the OS, a clean experience, etc. This means not only is the experience generally more "pleasing" for want of a better word, the apps around it are generally of a high, homogeneous quality as well: no negative association. Android are now starting to do this as well, as per this new announcement of a few days ago of a style guide. Believe it or not, Vodafone were doing this in 2009 with Vodafone 360 and Nokia did it with their own beta apps but that is it.
  6. Your target audience: How many people use and will pay for your service: you may get 500,000 downloads for free on one platform vs 50,000 paid for on another... quality is generally better than quantity.. (unless you are targeted on quantity, of course!)
  7. The submission, update and approval process
  8. The stats, settlement, promotion, how easy will you be to find on the store, etc
  9. what phones your analysts have (if you are quoted :))
  10. can you do it in HTML5, get the usage and adoption stats, build on what you know, not what you think... so much time, so many wasted features have been built over the years on assumption: just get it out there!
Hope this helps...