I’m currently reading a great book called Universal Principles of Design by William Lidwell, Kristina Holden, and Jim Butler. The book showcases the fundamentals of design and elaborates on many different concepts and principles which help designers approach development. If you’re interested in design or areas in this filed I highly recommend you give this book a look.
I’ve barely scratched to what this book has to offer, however I think the first principle or “rule” that is discussed is significant to us designers and developers of mobile applications, and in this case, iOS development. Below I’ll be analyzing how I feel this rule applies to developers and designers in the iOS field and how we can incorporate this into our work habits.
The rule is stated as follows:
A high percentage of effects in any large system are caused by low percentage of variables. The 80/20 rule asserts that approximately 80 percent of the effects generated by any large system are caused by 20 percent of the variables in that system.
[An example] of the 80/20 rule include
80 percent of a product’s usage involves 20 percent of its features.
Now that the rule has been stated, I want to take this principle into consideration and elaborate on how we can use this explanation to help us, including myself, approach development that incorporates natively with what we’re creating for. It can be as generic as mobile devices and specific as a particular section in iOS, like the Music application. I have broken down my analysis into three questions I think everyone should ask when developing or designing their application or product.
1) What are the core features of the system I’m developing or designing for?
This should be one of the first questions you ask yourself as you begin to design or develop the project you’re working on. The reason why this important is because, as stated in the rule, 80 percent of a system’s usage is determined by 20 percent of its functions. That’s huge. That exemplifies the fact that users use certain core features repeatedly and almost every time they enter the environment. Although this seems obvious, it’s extremely important for application development. To achieve the best outcome for your project, you need to consider how you can implement your project into areas where the core features are or in the path towards these functions. Otherwise, people won’t be as inclined to use your application or tweak because it is counter-productive to their normal, core functions. Whether you’re doing App Store development or jailbreak tweaks, it makes no difference. I’ll give an example for each:
Here are just a few factors you have to take into consideration:
- The SpringBoard layout (icon design)
- Native methods to do things (tapping, swiping, scrolling, etc.)
- Layout of content in your application
Although just a few are noted, these lend a lot of credibility to the fact that people want to experience the same applicational paradigms in every environment they are in. Consistency is important otherwise you’re bound to confuse a user when they are inside your application. Think about how iOS natively organizes things and try to stick to that sty;e. And if you deviate in a way you think is better, make sure you educate the user on how to go about using your application. They are used to the native way - you have to teach the alternative in an intuitive way.
Since there is more freedom to develop within specific core areas of iOS with a jailbreak, analysis in this manner goes to a different level. Here are just a few things to consider:
- Core features within a particular section or application (i.e. Music.app)
- Native layout of said area
- Implementation of native methods and functions
Similar to App Store development, people are used to navigating a certain way and using particular features or functions in the same way over and over. It’s simple as this; you confuse the user by changing up a native method without either educating or clearly designing or developing a way to help them learn, you lose the user from step one. Take consideration of the way things are setup natively and incorporate what you have in the best way to work together with what’s already there. And just like App Store development, if you deviate, make sure to properly educate the user.
I can’t stress this point enough because it is mega, ultra, important. I’ll summarize this section with this one phrase.
“If you don’t develop or design your application or tweak to fit in the existing environment and fail to educate the user if you deviate in a way you think is better, you’ll lose a lot of users - period.”
2) Does my project conflict with any of the “20 percent” features?
The section above is a perfect segway into this question so I’ll make this section brief. We know that much of a system, whatever that may be, is controlled by a relatively small portion of its features. If that’s the case, when designing or developing your project, you must make sure that whatever you have implemented doesn’t conflict or distort the usage of the existing core features.
Jumbling up the user experience by re-arranging where the user has to navigate to features they are used to using in a certain way will for sure get you negative reception. I’m not saying that changing up navigation is always a big “no no” but, if done at all, it needs to be in such a way that its easy for the user to learn the new way. If you think about it like a competition, your project is initially competing against what already exists. But the fact of the matter is that iOS was here first. With that said, we gotta play by its rules.
Conflicting with iOS’s native ways, if at all, must be done with great consideration and purpose. Bringing a user up to speed is not always easy, especially when you completely change something that they were used to doing one way. So, if you do decide to change things up, make sure your incorporation is done natively and that the method of doing “said thing” is easily learned or picked-up. And if not, make sure to build your application or tweak so that it works intuitively with the features people constantly use already. Otherwise, the user won’t be inclined to even bother with it.
3) How can I incorporate what I have into the existing core “20 percent” features?
This point is fairly straight forward. Whether you deviate a bit or stick to the “already paved-path,” you must take into consideration how to add what you have into what’s existing. As mentioned above, if you don’t stick to some native ways that users are used to, you’re alienating them out from the get-go. And remember, if you do change something, you won’t change every single method, function, and feature in that system - it’s highly unlikely. With that said, when you change something, look how it will incorporate with the other features. Does it work well with what you’re implementing it into? Does my project enhance as many areas of the system as possible and connects well with other parts?
I hope that you found this post interesting and beneficial for your current and future development endeavors! My goal in these posts is to help others pursue designing and developing for iOS in the best possible way. Apple gives a wonderful system to play with. It’s our responsibility to keep raising the bar and to continue to exemplify iOS’s simplicity and elegance.
If you have any questions or comments feel free to ping me! Even if it’s spelling or grammar mistakes! I’d love to hear your insight on this subject as well.
iDownloadBlog recently reviewed an upcoming tweak called MountainLionCenter which will bring the Mountain Lion-styled Notification Center to iOS. Although oriented towards the iPad, it works on the iPhone as well.
I have a few suggestions on how to make this project better, using the official Mountain Lion Notification Center as my guide. Note that these suggestions apply only to the iPad version.
1) Only the wallpaper moves, not the entire screen, when activating the Notification Center in Mountain Lion (SpringBoard).
I believe this point is extremely significant because it drastically changes the experience and purpose of the Notification Center. Here’s my justification:
iOS has multitasking (App Switcher) and, now with iOS 5, the Notification Center. When accessing the switcher, you’re make a conscious decision to move into another application. At that point, it’s appropriate for the user enter that view in the current window to fade or move aside. However, for the Notification Center, it’s meant to be an unobtrusive shade that is easily brought down and hidden without any disruption to the current activity. Accessing the Notification Center shouldn’t feel like you’re multitasking (in the iOS sense). I think there was a purpose in Apple’s choice to take the Notification Center as an overlay for iOS versus a screen pusher.
MountainLionCenter serves as a screen pusher at this point, but I think it can changed in this way to make the experience more of an overlay. On the SpringBoard, leave the dock and push the rest. And no need to fade the icons. Keep them the way they are.
2) The status bar does not move on Mountain Lion when the Notification Center is activated.
There are a two reasons why this is important. First, the way that MountainLionCenter (the tweak) does it now doesn’t make sense. If you look at the screenshot, the status bar in the Notification Center shade shows information that is still available to see on the actual page it pushed over (the time, bluetooth, battery percentage, etc.) Why display information twice? It looks weird.
Second, the fact that the status bar changes from something sleek to a linen texture looks pieced together. It doesn’t look good and doesn’t promote uniformity within the OS. Do it like Mountain Lion does it. Keep the status bar stateless. Move the content, keep the status bar. Then you won’t have to worry about re-showing certain info on the status bar because it will always be available to you from any view. Also, it eliminates having the two different types of bars merge.
3) The dock doesn’t move in Mountain Lion when the Notification Center is activated (SpringBoard).
This section is brief because I already proposed, from the SpringBoard, that everything is moved with the exception of the dock. Now that the dock is still there, do it like Mountain Lion does it. Have the Notification Center come underneath the dock so that the dock is on top over it. With this setup, you’ll also be able to use the applications on the dock without having to leave the Notification Center first. That’s one of the nifty things about OS X and how it handles the Notification Center. Anything outside of it takes priority. Not to mention, adding a two step process to opening a dock application when they are clearly right next to you doesn’t make sense.
I’ll leave you with this. When it comes to Apple’s intent of the Notification Center, I think its clear what their philosophy on the matter is: the Notification Center doesn’t take priority over the other core components. I think that’s a good point to refer to when doing anything with the Notification Center.
Photo courtesy of iDownloadBlog.
Since the first iOS 5 beta release, developers across the jailbreak community have rushed to create their own widgets on top of Apple’s existing options. The challenge from that point onward has been to build widgets that fit iOS’ existing frameworks; in other words, the goal is to integrate widgets natively into the operating system. The widget “playing field” recently expanded when Dashboard X was released, which allows users to place their widgets directly onto their SpringBoard. As a result, an entire dimension of widget real estate was added for the users to tinker with.
For those who know me well, I have professed on many occasions that widgets and my philosophy on the purpose of the Notification Center / SpringBoard don’t mesh well. I’m not completely closed to the idea, however I’m writing this post as a way to encourage developers out there to take the three factors below into consideration. I speak only for myself however my hope is that my suggestions are shared by others and that change for the better will occur as a result.
WWAD? - What Would Apple Do?
This is a huge concern of mine. When I look at any widget, my first question is, “Would Apple do it this way, in the event that they did?” Initially, think of it as a “What if” question. The reason why I chose iOS is because of its elegance, simplicity, and the overall experience it promotes. I can say with full confidence that many people share my view. With that said, when you’re creating a widget, be mindful that iOS users want to enhance their experience if it compliments the system they already love, not degrade it.
Take extra time to do “on-device research” to note certain design characteristics and paradigms that will help you build a widget that best integrates with iOS. I guarantee you that your success in development will fair much better if you go the extra mile and strive to promote iOS’ core strongpoints with your widget, versus simply “pasting” your project into the environment just because it adds a function. Great functionality is only appealing when it has great design; it’s a fact.
Widgets can be used in two different environments
As noted above, the Notification Center from day one has always been the main location for widgets. However, now that Dashboard X is out in the wild, the sandbox dramatically grew in size. With this in mind, you have to remember that your widgets can be used in more then one place. Unless you’re specifically designing your widget for one or the other (which I’m strongly against), take the time to design your project to fit all case scenarios.
Take this situation as an example: I am a user myself, just like anyone else. I don’t own or use Dashboard X. Let’s say that a really cool widget came out that I wanted but it was only optimized (in look and in its inner workings) for Dashboard X. That instantly raises my red flag. Why would I want this widget if it only works or looks good in one environment? Plus, I don’t even own or want to purchase Dashboard X.
My thinking is not exclusive to my stance on widgets. There are many people, naturally, who share this view. From the standpoint of downloads and (or) sales, you automatically cut out a huge section of your market when you don’t develop your project for all cases. You’re only targeting a relatively small piece of the iOS user base. Why would you want to do this? It’s a hinderance.
Everyone wants to be successful - it’s human nature. Success comes through demonstrating quality and excellence in whatever you do. If you have the opportunity to be successful to the fullest extent, wouldn’t you take up that without hesitation? You can do this with widget development. Take the environment into consideration and build a widget that works in each and every situation. You’ll see that people will be more inclined to take a risk and download or buy your widget. A first impression is huge, and you have the means to go off on the right foot from step one. This principle ties back with what Apple would do. They are targeting the entire mobile user base. If there are any components that don’t fit all case scenarios, they’ve instantly alienated a large group of people. I would say however that Apple has done an exceptional job of not going down this path.
You’re Not The Only “Big App On Campus”
I’ll keep this section short and sweet as it coincides with the above. Remember, there are many more applications and tweaks out there that are popular. You’ve got giants such as LockInfo and IntelliScreenX that dominate their area and their are, of course, other extremely well-favored applications that are the “numero unos” in their own domain. If you want to be just as successful, you must make sure to take other popular applications and tweaks into consideration and design your widgets to work well with all of them. Echoing from above, if you don’t, you cut your audience significantly when you don’t account for the other packages. Compatibility is key - make it a priority.
These thoughts are not meant to directly slander certain developers and their widgets. My hope from this is to encourage others to strive for excellence and quality in all that they build, create, or design when it comes to widgets. Apple gave us such an amazing system to play with. Let’s compliment the hard work they put into it by in turn firing back with the best we’ve got.
Promote excellence, not mediocrity.
As John continues to code Abstergo to how we both want it, I have expanded into other ideas to tackle after our project is done. The beauty of teamwork is continuous innovation. When one of us is at a standstill waiting for the other, opportunities to test and play around with new things gives a sense of direction after we’re done with our current focus.
Although no name has been chosen, here’s a small sliver of our next project; a SpringBoard manager. This manager is a vast and encompassing project and isn’t fully developed yet. Small parts have been brought from my mind to paper so as sections come together, I will showcase them to you.
This portion of the project highlights dealing with deleting applications and placing them into folders. It will include my multi-icon mover concept as well as new and unique functionalities.
Note: My idea for moving multiple icons has changed slightly from the concept above. Information on how I want it to work will be revealed as time goes on.
I won’t let out too much information, but I will let you know about a couple of things pertaining to this part.
- - You will be able to multi-select applications
- - With multi-select, you will be able to folder them instantly as well as delete them with ease (individual and multiple)
- - The drawer as shown in the pictures will be available to you only in Wiggle Mode and can be revealed by pulling down in the SpringBoard
- - There will be a lot of animations (just enough to be appealing to the user of course)
And to top it off, there’s much more than meets the eye. Feel free to ask questions and I will do my best to answer them accordingly.
The Question Mark: I spaced on what I originally wanted in that box and I’m searching for the lost recollection of my idea. If you have any ideas, feel free to shoot me them. Hopefully I figure out what I wanted there!
I leave you with a quote from a man who we’ve all come to cherish and love. For his inspiration and impact on the world. His definition of innovation is what absolutely defines my experience; it’s powerful.
“But innovation comes from people meeting up in the hallways or calling each other at 10:30 at night with a new idea, or because they realized something that shoots holes in how we’ve been thinking about a problem.” - Steve Jobs
Until next time.
WARNING: Anything and everything is subject to change.
© 2012 Joshua Tucker
The number one question I get when I post anything on my Tumblr is “Where can I download this or when will it be available?” For this reason, I figured I would explain myself:
Everything that is initially posted on my Tumblr is a concept unless otherwise specified. This may come as a disappointment to many of you, however I’m here to say that I only create concepts that I feel would be worth pursuing and developing. In other words, I fully intent on getting these projects developed in one way or another so don’t let your sprits drop!
When it comes to bringing a project to life, the hardest first step is finding the right person to work with. Expertise, personality, and a friend relationship are the three main characteristics I look for when I’m scoping out potential partners. Entrusting the vision of your project into the right person is vital for the success of the application, so naturally, the selection process is rigorous. I have high standards for how I want things to work and operate and my expectation is that my co-partner is on the same path and shares the same goals as I do.
Now to the fun part. I have begun my first project based on one of my concepts with John Heaton. He’s the developer of tweaks such as MarkThatMessage, BadgeClear, and Locktopus, plus he’s a great friend of mine. My decision to approach him with my project was deliberate and I know that I made the right choice. Without further to do, I’d like to officially announce our first project together - Abstergo.
Abstergo is based off of my lock screen notification clear concept and is going along quite well. There are obviously hurdles to get this functionality to run smoothly and efficiently, but John has done a wonderful job of taking each chunk one at a time and I’m excited for each new step. The picture above is what we have done thus far.
To alleviate any questions you may have, skim below to get an overview of what we’re willing to answer at this time.
1) First of all, why would you name it Abstergo? That’s a really odd name!
Well growing up, my first language I actually studied in school was Latin. As a result, many of the words and phrases I learned make up a great word bank of names to choose from! They all have significant meanings and definitions and are the foundation for languages such as English, French, Romanian, Italian, and Spanish (plus any other Latin based languages)
Abstergo in Latin means “to clean or wipe away.” For you Assassin’s Creed fans out there, the use of Abstergo is because the group’s purpose was to “cleanse” the world of assassins, or basically their enemies. A domination technique.
Because managing lock screen notifications will require you to clean or wipe away the badges from the screen, I found it to be an appropriate fit. The name is not set in stone, however I’m almost 100% sure this is it.
2) What kind of progress have you made? Is there an ETA?
All we will say at this time is that progress is definitely happening. Giving out an ETA will only setup us up for failure because really, we’re not sure how things are going to play out as things move forward. Since we are both perfectionists, we want to ensure the user experience as well as the coding efficiency behind it are on par. For this reason, we would appreciate all you users to refrain from asking ETAs, although we won’t rudely respond to you if we do answer those types of questions here and there.
3) What will Abstergo do?
Since it is a a lock screen notification manager, it will allow you to do the following:
- Clear individual notifications from the lock screen
- Clear all notifications from the lock screen
- Mark individual notifications read from the lock screen
- Mark all notifications read from the lock screen
Obviously things will change in terms of additions and how it will work, but those four things are our goal at this time. At some point, we will post a video about how it works since a simple photo doesn’t give it justice.
4) What’s the compatibility with Abstergo?
Abstergo will be available on all devices capable of running iOS 5.
5) How much will Abstergo cost?
We haven’t come to a conclusion on that. Whatever the pricing is, we won’t charge anymore than what it is worth.
6) How can I stay updated on Abstergo’s progress?
Follow both John and I on Twitter. At the very bottom of the post, both our Twitter accounts are linked for your convenience
These are all the questions I’ve come up with thus far; if more questions come in, I’ll add them to this list. You’re welcome to comment below if you have any questions, feedback, or suggestions.
Until next time!
© 2012 Joshua Tucker
CallBar is 50% off for a limited time (one week)!
CallBar has come a long way since its first design, as you can see from above — through the version updates, CallBar has evolved into a very comprehensive application. It has become one of the most popular phone tweaks from Cydia as well as an overall favorite for all iOS users. Both Limneos and myself couldn’t be more excited and thankful for all the support you guys have given us.
We surpassed 8000 purchases today, so in light of the holidays and this accomplishment, we dropped the price of CallBar from $3.99 to $1.99 for one week. Grab it if you haven’t it and make sure to share this awesome news with friends!
If you’re unsure about what CallBar is all about, make sure to read the depiction.