About
Friends
-
Loading…michellzappa 10 months ago -
Loading…Yee about 1 year ago -
Loading…dscape about 1 year ago -
Loading…brook 16 days ago -
Loading…heatherlipner 3 months ago -
Loading…mjesales about 1 month ago -
Loading…avinash over 2 years ago -
Loading…technofetishist 14 days ago -
Loading…onwhite 2 months ago -
Loading…minima over 2 years ago -
Loading…kadesoto 14 days ago -
Loading…olivertaco over 4 years ago
Click here to check if anything new just came in.
April 21 2012
Screenshot of the new iPhone application I am working on.
February 22 2012
How To Create a Rotating Wheel Control with UIKit
There may be times you’ve downloaded a cool application with a new kind of user interface component, and you’ve wondered: how was it built? One great example of this is the rotary wheel, used by ConvertBot and other applications as a way for users to select options from a menu. This component is intuitive to use because it resembles many similar controls we use in real life to make choices. For example:
- A ship’s wheel allows the captain to choose the direction of travel.
- To set the volume of your stereo, you use a rotary knob.
- You might also remember that we used to call people using rotary dial telephones.
Such shared knowledge allows us to recognize the “possible uses” of a rotary wheel, even when it’s a virtual wheel.
Note: A perceived use of an object is also called an affordance, a concept used in such fields as psychology, design, and artificial intelligence.
In brief, a rotary wheel is meant to be spun. Just as with hardware wheels, touchscreen wheels can be configured in many ways. For example, we might include stop points (as in the rotary dial on a phone), ignore initial taps in a given zone, allow just one direction of rotation, etc.
As you may have deduced, this tutorial will show you how to build an intuitive rotating wheel interface. You’ll then be able to integrate this component into your iOS apps and let other people wonder how you built it ;]
Read the rest on raywenderlich.com
February 06 2012
Soon on raywenderlich.com
Written by Cesare Rocchi - studiomagnolia.com
Cast: funkyboy
Tags: iOS, rotary wheel and custom uicontrol
January 04 2012
Android’s throat is now exposed
This article from Business Insider got me started. Since I have to time to address potential fanboy arguments let’s go this way. For each time you think I am a fanboy I’ll think of you one of the following:
- troll
- user who has time to loose with lower quality devices/experiences
- user who likes to accumulate stress
Right now that Eric Schmit is promising that Android will soon beat iOS (whatever is the meaning of beating in this context), Android’s throat is getting more and more exposed. I can’t provide evidence but I started to feel a while ago that Android has found his way: more and more devices released and much buzz around the topic. But I always got in mind a few key aspects:
- Fragmentation: it is not easy at all to build an homogeneous experience across many different devices
- Too much fanfare about the number of devices activated per millisecond
- Nobody has ever revealed how many dollars has Google shared with developers
While the second is mainly related to marketing and the too much diffused tendency to reveal meaningless numbers, as a UX designer, developer and entrepreneur I am pretty sensitive to points #1 and #3. The first is pretty a technical reason: developers have to write more code and carry more stress with respect to iOS. The third point is pretty a mystery to me: Apple is known to be pretty secretive, especially when prototyping, but is proud to reveal key numbers to attract more on their platform. Rhetoric questions for developers/entrepreneurs: which market would you dive in? the one where you know the current volume or the one you don’t know anything about? While reflecting on this please don’t fall into the childish thought that “more devices more potential buyers”, unless you are a rookie. Just consider that you are making money by selling applications, and a higher number of devices does not imply a higher number of sales. The key value is the “willingness to buy”, and the internet is full of articles supporting the idea that iOS users are more prone to buy applications than androiders.
Getting back to the main point of this article the new announcement from Samsung, that won’t allow upgrades to the new version of the OS on old devices, is really exposing Android’s throat to attacks. While it was relatively easy to copy (umm … take inspiration from) iOS and its ecosystem, now I think that Android has reached a pretty unsolvable issue: the one of upgrades. People who bought an iPhone 3gs (released in June 2009) can still happily use it today with iOS5 and the iCloud. Can you find a similar example in the Android world? I doubt so. The reason is exquisitely technical: relatively young devices have not enough hardware power to run new versions of Android OS. It is just a physical limit, and I think there is nothing to discuss. My opinion is that it is due to lack of vision. One of the few upgradeable devices is the Galaxy S2, because it is a flagship product, and preventing an update on that would mean users migrating to other devices in a hurry.
I am not a fan of Microsoft but if you bought the first model of Windows Phone you can still happily run the latest version of the OS on that. This means being on track.
Besides technical reasons I think that there is an issue related to the approach. While it was possible to “decouple” hardware and software on the desktop (and Microsoft has built his empire on that) this is much less doable in the mobile world, where hardware power is limited.
Here are a few suggestions for Google, makers and users.
Makers
HTC, Samsung and colleagues should follow Amazon approach. The only way to attack a well established market are a few. You can work on:
- the best product
- the best solution
- the best price
Amazon, to attack the tablet market, is betting on the best price. I don’t see a simpler way for competitors to undermine Apple’s iOS ecosystem. Building the best product or solution would take a lot of time.
Google should close the gates, reorganize all the code to be more tightly coupled with hardware. They should put a lot of effort in rendering, demanding that (when possible) to the hardware. They should also devise crystalline rules about installation and updates. In 2012 I should not connect my phone to a computer to update the OS and I should not be forced to buy a new device to have the latest version of the OS. The recent acquisition of Motorola
is going toward that direction. If I were HTC or Samsung I’d be a bit worried, for I suspect new versions of Android will be super optimized for Motorola hardware. That’s the only solution I see for Android to resurrect.
Users
In the current situation, my suggestion is to go cheap. If you buy a $500 Android phone which is not OS-upgradeable it is not easy for you to afford a new purchase. If you have bought a $200 one, you have saved $300 (with respect to an iOS device) and you can think of using that money to buy a new model in one year.
Of course it is not easy to spot which models are upgradeable before you buy them (see crystalline rules above).
In general, we are told that a Google-approved Nexus device, should be eligible for upgrades (my addition: provided that hardware is powerful enough). So if you really like to buy an Android phone/tablet I strongly suggest to stick with those models or buy the new ones which will be released by Motorola in 2012.
Conclusion
While Google and friends are just chasing the highest number of activations per day, exposing his throat to competitors’ weapons, Microsoft and Apple are pointing on good experience, simplifying data migration and assuring compatibility with old models.
I’d like to conclude with a set of questions:
- where is all the “freedom” that Android supporters claim?
- do you realize that openness and (supposed) freedom, in the long run, are more costly than “closed-source” competitor solutions?
- do you see all the ifs you are going to face buying an android powered device?
- do you know that all this is due to a business model
- Not convinced yet? Have a look at this graph.
?
November 17 2011
October 31 2011
Getting started with iCloud
This is an excerpt from my chapter on iCloud included in iOS5 by tutorials.
We all have “stuff” we use on our iPhones and iPads regularly like documents, pictures, videos, emails, calendars, music, and address books. But how many times have you tried to quickly open a document and realized “argh, I have it saved onto another device”?
Well, with the new iCloud feature in iOS 5, that is problem of the past!
iCloud is a service that helps you synchronize your data across devices. It is a set of central servers which store your documents, and make the latest version available to every device/app compatible with iCloud (iPhone, iPod, iPad, Mac, or even PC).
In this tutorial, we’ll investigate iCloud by implementing a set of simple applications which interact with cloud servers to read, write and edit documents. In the process, you’ll learn about the new UIDocument class, querying iCloud for files, autosaving, and much more!
Note to get the most out of this tutorial, you will need two physical iOS devices running iOS 5 for testing, such as an iPhone and an iPad. The simulator does not currently have iCloud support.
Under the Hood
Before we begin, let’s talk about how iCloud works. In iOS each application has its data stored in a local directory, and each app can only access data in its own directory. This prevents apps from reading or modifying data from other apps (although there are some alternate methods of transferring data between apps built into the OS). iCloud allows you to upload your local data to central servers on the net, and receive updates from other devices. The replication of content across different devices is achieved by means of a continuous background process (daemon) which detects changes to a resource (document) and uploads them to the central storage.
This works real-time and enables another interesting feature: notifications. For example, whenever there is a conflict about a document, the application can be aware of that and you can implement a resolution policy.
If you ever tried to create something like this with your own apps, you know there are several major challenges implementing this:
- Conflict resolution. What happens if you modify a document on your iPhone, and modify the same document on your iPad at the same time? You somehow have to reconcile these changes. iCloud allows you to break your documents into chunks to prevent many merge conflicts from being a problem (because if you change chunk A on device 1, and chunk B on device 2, since chunk A and B are different you can just combine them). For cases when it truly is a problem, it allows you as a developer fine-grained control over how to handle the problem (and you can always ask the user what they would like to do).
- Background management. iOS apps only have limited access to running tasks in the background, but keeping your documents up-to-date is something you want to always be doing. The good news is since iCloud synchronization is running in a background daemon, it’s always active!
- Network bandwidth costs. Continuously pushing documents between devices can take a lot of network bandwidth. As mentioned above, iCloud helps reduce the costs by breaking each document into chunks. When you first create a document, every chunk is copied to the cloud. When subsequent changes are detected only the chunks affected are uploaded to the cloud, to minimize the usage of bandwidth and processing. A further optimization is based on a peer-to-peer solution. That happens when two devices are connected to the same iCloud account and the same wireless network. In this case data take a shortcut and move directly between devices.
The mechanisms described so far are enabled by a smart management of metadata like file name, size, modification date, version etc. This metadata is pushed to the cloud, and iCloud uses this information to determine what needs to be pulled down to each device.
Note that devices pull data from the cloud when “appropriate”. The meaning of this depends on the OS and platform. For example an iPhone has much less power and “battery dependency” than an iMac plugged into a wall. In this case iOS might decide to notify just the presence of a new file, without downloading it, whereas Mac OS X might start the download immediately after the notification.
The important aspect is that an app is always aware of the existence of a new file, or changes to an already existing file, and through an API the developer is free to implement the synchronization policy. In essence the API allows an app to know the “situation” on iCloud even if the files are not yet local, leaving the developer free to choose whether (and when) to download an updated version.
October 27 2011
the understatement: Android Orphans: Visualizing a Sad History of Support
The announcement that Nexus One users won’t be getting upgraded to Android 4.0 Ice Cream Sandwich led some to justifiably question Google’s support of their devices. I look at it a little differently: Nexus One owners are lucky. I’ve been researching the history of OS updates on Android phones…
October 06 2011
October 01 2011
September 26 2011
September 25 2011
September 24 2011
Rome (literally) (Taken with instagram)
September 23 2011
September 03 2011
This is genuinely Microsoft’s idea of a “streamlined”, “optimized” UI for Windows Explorer. They were so proud of it they wrote a blog post about it.
The post is a sort of masterpiece of crazy rationalization, but I think my favourite part may be this screenshot:
Here, they proudly overlay the UI with data from their research into how often various commands are used. They use this to show that “the commands that make up 84% of what users do in Explorer are now in one tab”. But the more important thing is that the remaining 50% of the bar is taken up by buttons that nobody will ever use, ever, even according to Microsoft’s own research. And yet somehow they remain smack bang in the middle of the interface. The insanity is further enriched by this graph:
Again, this is Microsoft’s own research, cited in the same post: nobody — almost literally 0% of users — uses the menu bar, and only 10% of users use the command bar. Nearly everybody is using the context menu or hotkeys. So the solution, obviously, is to make both the menu bar and the command bar bigger and more prominent. Right?
Microsoft UI has officially entered the realm of self-parody.
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...




















