literaryjukebox_layout

I have created a simple chart for the dimensions of iPhone app screen. The width is 320 pixels while the height is 480 pixels. The main navigation bar should at least start from 50 pixels but I have come to the conclusion that 60 pixels average is the best size. You can still divide bars equally and to a good dimension.

From the top we also loose 20 pixels. When these dimensions are deduced you get your playground.

Five Most Frequent iPhone Design Mistakes

The five most frequent iPhone design and usability mistakes, and how I plan to deal with them.

• Over-blown visuals.

Probably the oldest, yet extremely popular design problem is overdesign. Designers of iPhone applications often tend to disregard common design and usability conventions by offering users slick and shiny user interface designs that go way beyond their standard look and also way beyond their claimed functionality.

Why make things look, feel and work complicated and why do designers like to re-invent the wheel? The answer is simple: they want the application to be different; look different and stand out from the crowd. Unfortunately, a different look isn’t necessarily helpful for application’s usability and functionality.

So how does an over-design in iPhone applications look like? To better understand it, let’s look at an example:

 

At first glance this design might look slick to you, but it has lost it’s focus. This is supposed to be a settings screen and it is different from what the users are used to. The multi-touch gestures are not the same, and over designed.

Noticed the difference? Being inconsistent with other products makes yours worse for two reasons:

1. Going against convention makes your application less intuitive. Over-styled controls look different and require users to re-learn how they work.
2. It’s a waste of time and money. The resources you have spent to make your app look different, but not necessarily better, could have been used much more effectively.

The application will be unique in look but the controls used will be the standard IOS controls.

HERE IS WHAT I’M SIMPLY GETTING AT; WE SHOULDNT BE RE-DESIGNING CERTAIN ASPECTS JUST TO MAKE THEM LOOK PRETTY, OR PEOPLE CAN START DYING.  🙂

• Neglecting technological limitations, such as slow Internet connection, slow processors and single-threaded OS architectures.

• Confusing navigation (flow, layout and taxonomy).

• Confusing the iPhone with a computer. Neglecting to use new iPhone interactions (fingers instead of the mouse; multi-touch gestures; turn, tilt and rotate) and technological features such as phone functions, built-in GPS and accelerometer.

• Disregard of context. A lack of understanding of how, when, where and why the mobile device is being used.

lj_poster

Since I have no prior knowledge of the programmes I’m going to use, I decided it would be best to ask around. There seemed to be many program me names involving the design of an application, so I specifically decided to ask what was adviced to me in class. here are the feedbacks;

SWIM 1:

The difficulty you’re going to have if you have only coded Java is pointers and memory management. Memory management isn’t conceptually hard as it’s simply (!) a question of keeping track of what you are allocating and releasing, plus XCode seems to come with good tools for detecting leaks (although I haven’t used these in anger yet) – and as iPhone programs are relatively small it’s not like coding a big system program where this can be extremely tough. The major conceptual difficulty you are likely to have is simply getting your head around pointers as they are used extensively (as in just about on every line of code) and you do need to grok these completely. One of Joel’s reoccuring themes on the podcast is the difficulty some coders get using pointers, so I’d recommend you take that carefully and possibly pick up a good book – perhaps the original K&R.

SWIM 2:

To answer your question the biggest hurdles are understanding the conventions (Delegate pattern, Categories, etc.), getting a grasp on memory management, and working with XCode (a good IDE but definitely steps behind Eclipse and IntelliJ).

SWIM 3:

I came out of college as Java developer. My first (real) job was Mac Development. Transitioning from a language I know (my starting point was Java) to something like Objective-C was fairly easy, code-wise. To maximize your time developing iPhone / Mac Applications, you have to make use of XCode and Interface Builder. Once you get the hang of attaching events and GUI outlets (the objects your UI want to communicate with), you’ll be set for normal iPhone app development.

SWIM 4:

Here are the steps I went through learning Objective-C (the programming language for iPhone development) having my Java background:

1. Learn the basic OC object-oriented concepts. Subclassing (Inheritance), protocols (Java Interfaces), object properties (Bean properties), methods (you have to explicitly indicate the “parameter entry” labels, unlike in C / C++ / Java where you guess the parameter ordering).
2. Understand the difference between Objective-C, Cocoa, Aqua, and C. Then learn about how to use frameworks. Frameworks are pretty much the same as Java Packages.
3. Familiarize yourself with using these Foundation classes: NSString, NSArray, NSDictionary, NSSet, NSURL, NSAutoreleasePool.
4. Study more about Interface Builder. I thought before that the Visual Basic way of programming limits the programmer. I was wrong. It is better you “visualize” the app first before you get the hang of how things go in it. Take note about the keywords IBAction (analogous to making an EventListener), Outlets (you only have a few objects “exposed” for your UI elements), Views (UIView in case of the iPhone, everything that’s “visible” in the application can be considered a “view”), and Controllers (there are ready-made controllers that you could use to populate Table Views, flip Card Views, etc.).
5. Learn how to deploy your app through the iPhone Developer Portal. You cannot send any iPhone app to any device if you don’t have this “right”. Yeah, I know it sucks, but you have to go through this process, anyway, if you want to sell your apps.

First Draft:

va402_OLD_project proposal_ipekel

Final Draft:

VA_402_PROJECT_PROPOSAL_FINAL_IPEKEL