The Wonderful World of Computer Graphic User Interface

As WWDC 2013 is over, some of the respectable opinion leaders share their thoughts on iOS 7’s new look. I would like to share links to their posts:

I admit, I’m quite biased in selecting these posts, having positive perspectives.

Surprisingly, there are some common understandings I could find, and have come up with myself, about iOS 7’s new look. Though I’m not a professional designer, or an influential leader like the ones above, I think it won’t be too bad to write one more post about iOS’ User Interface.

Representation by Animation: Until recently, objects or ideas have been represented by visualization. However, instead of bringing full detail from the looks of the objects shown in the real world, iOS 7 chose to use subtle or obvious animations of the objects, or about the ideas as the essential representation method. Please watch the video about Apple’s Design Intention, and recognize how different animations have been used to identical circular dots, to represent many different objects and ideas. This shift can be a great opportunity to those who believe in the apps to be more dynamic and alive, and a great challenge to those who are so used to draw beautiful but only static images.

Content Supremacy: iOS 7’s extremely minimal buttons and labels remind us what we’ve been forgotten; that the app’s main content must have full attention. If pixels or focus inside the device’s screen cannot be shared, so fighting between the main content and user interface controls cannot be avoided, iOS 7 voluntarily yield user’s attention to the main content, by making the controls so thin, translucent & borderless. Because they occupy so little area or look so simple, they can help the main content to be stood out automatically. However, what should not be misunderstood is that, the limitation on the controls can be ignored if they are parts of the main content.

Space Telescope: It’s not that easy to bring fluid transitions between views, but iOS 7 provides new methods to help the developer to implement them as easy as possible. I think it is to encourage the device’s screen to be utilized like a telescope showing one area of much bigger space, which includes more contents yet to be shown, until the device’s screen is looking toward them. The concept of panning & zooming from scrollable views have become more adoptable into view transitioning. Personally, I really like this. (Don’t know how to express in clearer form but…) This is to motivate the apps to bend more space and time, which is no real world medium will ever be able to do.

Still, it is Beta 1. I wonder how the end result will be for the look of iOS 7. But, at least for now, the heading of this exploration is showing the glimpse of the wonderful world of computer graphic user interface.

Advertisements

Fully informed and experienced decision

My comment for “Why I Don’t Use Interface Builder”: http://blog.teamtreehouse.com/why-i-dont-use-interface-builder

IB is about Organizing, not about Replacing. IB is a tool, not a regulation.
Once you know the limits of IB and developed good programming habits, IB can be extremely useful.

I saw too much terrible spaghetti codes, which could have been helped by adopting MVC principles and knowing the life cycles of UIViewController & UIView instances.
As a way to help those developers to learn about the principles, I show them how to complete a project using IB and later replace it using only codes, to help them to realize the limits of XIB files and see how whole structure is preserved, to show the real reason for using IB: Separating codes.

And once VIEW components are separated from others, I point out patterns or repetition, which are just configurations at loading of the instances.
Other than iteration, they are not so easy to be solved creatively and quickly, without taking precious seconds, minutes, or hours.
Also, there are more important tasks for fulfilling the requirements of the app, than tasks for calculating frames for labels.

Unless you like it (I saw some people who like it), it’s smart or even necessary to use a tool which was developed to avoid working mechanically. Fortunately in Xcode, we have Interface Builder.

Depending on the characteristic of the projects, the decision to use or not to use IB is totally up to the developers. When they decide not to, I hope it’s fully informed and experienced one, instead of one caused by estranged or uncomfortable feeling toward IB.

Developing New PopToo

As PopToo, specifically the Classic version, is taking a break, New PopToo is busy being developed.

With the strong desire of the developer to try latest iOS methodologies, slowly but steadily, new looks have been tested and new ways to make the experience more enjoyable have been evaluated.

PopToo's New Look

Above image is showing not yet finalized look, but the main idea is to use the map as large and prevalent as possible.

Previously, I posted about my big hope for Google Maps iOS SDK. Without being actually disappointed at it, I have realized what I really needed for PopToo’s map.

Though Google’s map is great for showing regional information, the images are still bitmaps. For PopToo’s use of the map is focused around adding annotations, support for drastic zooming or scrolling, with better animation and rendering rate is more important.

Also, Google’s APIs are not really free. Until I can find the right strategy for PopToo’s growth, I can’t help but to delay my final decision to use Google Maps iOS SDK.

For now, the previous plan has been changed to use iOS’s original MapKit. Even though I recognize the many disadvantages of current MapKit, rather I am willing to make PopToo to complement it with the great features.

You can see them soon. Hope you would like them.

Don’t punish Yourself

It’s given as a PUNISHMENT to a student to write sentences REPEATEDLY on a blackboard.

If you are not careful, it’s quite easy to REPEATEDLY paste copies of identical code snippets. Not using iterative methodologies and not trying to find algorithmic solutions, is like let yourself to be in the state of uncomfortable incompetency, which is a PUNISHMENT.

Sensitive Programmer

As a learner of programming, you may feel stressed and uncomfortable, trying your best to maintain control over the machine, not to be controlled by it.

There are too little time to complete the assignment. Your mind is not clear enough to come up with the best structure of different classes. Inheritance, polymorphism, DRY, MVC and all other essential concepts about quality programming are just ideas without visible lines of codes.

Even if you could finish your work on time, it’s quite painful to see resultant chaos in your own codes. You don’t like your own work, knowing every line in it. And this is a good thing.

Being sensitive enough to realize inefficiency and incompetency in your own work, even if no one criticize it, is a great attitude, especially if you are a beginner. Congratulation! Make sure to keep it as sensitive and sincere like that.

Until you become a true master of programming, who can bring undeniable great architectural solution without taking too much time and resources, please don’t try to avoid or ease the pain for producing quality result.

It’s necessary to feel the inefficiency of scattered snippets within your codes. You need to experience the frustration of attempting to change a small thing, repeatedly about thousand times. After experiencing this, you will never forget the critical importance of DRY principles and will force yourself to learn how to use global variables and methods, apply proper hierarchical relationship among classes. Soon, it will become natural to you as you become a better programmer.

However, it you let yourself to be insensitive to pain while programming; e.g. listening to music or copying & pasting mindlessly; you will lose the opportunity to see the need to improve. Simply for the sake of finishing the work as soon as possible, you will just pass by the situation which may teach you very important principles.

Such insensitivity will bite you back, as you maintain the chaotic structure, slavishly patching the effects without fixing the causes. And finally, you will give up, unless you can start all over again.

Google Maps iOS SDK

UPDATED: Lately, my opinion about Google Maps iOS SDK has been changed. Quite drastically, after experimenting more with Apple’s MapKit, and having much clearer about the requirements of PopToo, adopting Google Maps may stay optional for a long time.

Google Maps iOS SDK has been announced, and developers can register to receive API keys: https://developers.google.com/maps/documentation/ios/

I personally have been anxiously waiting for this announcement, believing this SDK should come before the end of this year.

While struggling with myself in making enough time to develop new PopToo, or even to upgrade PopToo Classic for new 4 inch display, I can’t help but suspecting if Apple’s MapKit is really the right choice for PopToo. Naturally, I had to believe Google Maps should be available for developers as SDK, and now it’s realized.

Google Maps’ ubiquitous accessibility including web browsers, makes the service definitely superior to others by itself. Also, this ubiquitous accessibility fits great with PopToo’s plan to expand toward web application.

I’m still reading the documentation. I’m only confident that available features in this SDK will be useful for new PopToo. This announcement alone was able to re-invigorate my motivation to accelerate developing new PopToo.