How Facebook’s New Chat Drawer Increases Inconsistency
Facebook updated their iOS application today and incorporated a new chat drawer for the iPhone and iPod touch. It’s essentially the same as the left drawer but accessed from the right side. There were a lot of other features that were added as well however that’s not the focus of this rebuttal.
I am writing this because I feel that the newest drawer addition continues to make different parts of the Facebook application inconsistent and confusing for the user. I have broken each point into its own section for better understanding of why I feel this analysis matters.
News Feed:
The News Feed page is the same as before with one exception; a new chat button on the top right side. On top of adding the button, the new drawer can shown by swiping from the right to the left, which means the News Feed has dual side gestures to show different drawers. This presents a problem. Native cell swipe handling has been compromised.
Using Mail as an example, users are coached to understand that swiping a cell presents a Delete button. No matter which way you swipe, the button is presented to ensure both left and right-handed people can perform the action with ease. This pattern is engrained as default all over iOS and is a known paradigm for other applications that choose to use it correctly, whether it’s a Delete button or not. Due to how Facebook handles the drawers currently, it makes it impossible to integrate any of those features in the future:
1) Deleting my own posts from the News Feed
2) Hiding posts
3) Reporting for spam
The second and third point are not features available in the mobile application. My question is why not? They very well should be and are just as important from the mobile platform as it is from desktop. These are just a few ideas for what could be added.
You may be thinking that this isn’t such a big deal, but wait until the connection is made with the section below.
Profile Page:
If you go to your own page, nothing has changed – which is a problem. Note that the Chat button is not available on the top right side of the bar. Why? Having access to the chat feature is just as important here as it is on the News Feed. Why limit a core feature and require the user to perform extra steps to reach it? First inconsistency.
Second, the cell swipe handling becomes super sketchy here. Let me list what each swipe in this view does:
Swipe Left (Page): Shows “X” button to allow you to delete a status
Swipe Right (Page): Shows main drawer
Already at this point, it diverts from what is being used in the News Feed. Consistency is vital to user interaction; it’s absolutely invaluable. A feature is being limited and made harder to access and the handling completely changes. Not good. Second inconsistency.
Third, I mentioned above that the chat drawer can’t be accessed from the profile page (or other pages). In fact, it can. But, it’s strange. If you swipe the navigation bar from right to left, the drawer appears. Again, why? Is the lack of a chat button a bug or deliberate? If it’s a bug, then that’s fine, but either way it still adheres to my concerns. And if it’s deliberate, why hide it? Bad news bears.
Note: The handling of the profile page is the same for all other pages.
My Solution:
In light of my points, what is my solution? I could discuss how I feel the view should be changed completely, but for the sake of my argument, let’s go with the best way to optimize with what we’ve got. Here’s my proposition.
1) Keep the default cell swiping paradigm consistent in all places. Allow the user to swipe either way on a cell to be presented with options such as delete, hide, or report for spam
2) Show both the Main and Chat button on the navigation bar everywhere. Accessibility from everywhere is extremely important
3) Still have the ability to swipe open a drawer by restricting the swiping to only the navigation bar or make the off-screen gestures more precise. Leave 98% of the page adhering to default cell swiping and make the edges a way for you to more deliberately swipe across and access the drawers.
Feel free to hit me up on Twitter to continue this discussion or with questions/concerns.
© 2012 Joshua Tucker
NOTE: I thought long and hard about whether this post would break iOS 6 NDA. I concluded that it was discussed in the keynote and is viewable on Apple’s website, so I deemed it as not being an issue. However, if this is not the case, please let me know and I will gladly remove it.
Also, I explain in the post why my implementation is different from what is currently available.
——————————————————————————————————-
One of the new incorporations with iOS 6 is the pull to refresh feature in Mail. If you read my recent article about Pull to Refresh in Safari, you will know that my philosophy on pull to refresh is rather unorthodox. My goal in whatever I design or conceptualize is to build it in a way that makes it unobtrusive and available no matter where you are in the view. With that said, I wanted to make pull to refresh work in a way that allowed you to do that. In this case, I wanted my philosophy to hold true in the Mail application. So, I’m bringing back my handy-dandy two cell checklist of my view on what I want with pull to refresh:
- The ability to pull and refresh (obvious)
- Being able to pull and refresh and remain where I am in the scrollable view
This piece is a rebound off of my Pull to Refresh in Safari concept except I incorporated it into the Mail application. There are some slight differences for those who read my previous article so make sure to read which section carefully which are divided for your convenience.
——————————————————————————————————-
1) Pull to Refresh View
The first section showcases how I think the pull refresh view should be. At this current time, the pull to refresh view is located within the scroll table which means you have to be at the top to refresh it. To allow the user to refresh from anywhere, I designed it so it can be pulled from the navigation/header bar. Simply drag down from the top and it refreshes no matter where you are in the view.
Although not viewable in photos at this time, I see the refresh view displaying important information like the number of new emails (if applicable) and a loading bar for new emails coming in. This would eliminate having to scroll back up to see if any new mail has come in. It will display a summary briefly at the top and then close the gap again. I will work on that implementation soon, but for the time being, note that the refresh view in my mind has a lot more purpose than what it’s currently used for.
2) Navigation/Header Bar
Discussed briefly in the section above, this bar will be the initiation point for the pull to refresh. No matter where you are in the view, if you drag down, the view will slide down and refresh. Short and sweet.
3) Scroll View
Although shown at the top, since the header bar (All Inboxes/Specific Inbox) is always visible at the top no matter where you are on the scroll view, it’s fairly easy to initialize the pull to refresh. Again, short and sweet.
——————————————————————————————————-
This implementation would be available on all iOS devices.
√ The ability to pull and refresh (obvious)
√ Being able to pull and refresh and remain where I am in the scrollable view
© 2012 Joshua Tucker
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.
Kindle - Amazon (Older edition)
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.
80/20 Rule
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.
Analysis
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:
App Store:
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.
Jailbreak:
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?
Conclusion
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.
It would seem that lately the idea of creating an easy application launcher from the lock screen has been on a lot of developer’s minds. The key point of change has been the camera button. Whether it’s sliding or tapping, I feel that the methods many of these developers are using are non-native or intuitive.
In a rebuttal, here’s my approach to designing a more user-friendly method of launching applications from your lock screen using the space allocated for the camera button.
Note: I’m still learning and growing and always appreciate feedback and suggestions. This post is meant to be a helpful tool, not a way of tearing people and their work down. What follows is my opinion based on own personal experience in this field.
Analysis
Let’s make sure to take these into consideration:
1) You’re not going to want more than five applications available to you
You don’t want to clutter up your lock screen with various buttons and toggles. It’s distracting to the user and makes it easier for someone to accidentally press something. Keep it to a minimum; you’re wanting the applications you use the most, not your entire SpringBoard.
2) Sliding is not the answer
The only components on the lock screen that slide are notifications and the slide to unlock bar. Adding any more sliding, especially near the slide to unlock bar, could cause confusion and make it more accident prone to sliding an icon you don’t want. It also tends to cover up the slide to unlock bar which looks funky and portrays a sketchy implementation. Users tend to associated certain methods in an environment based on past experience. Utilizing familiar actions that are generally used for other important methods could make the user’s experience more cumbersome.
3) Not all the applications have to be viewable at one time
At most, keep one in view. The lock screen is not meant to be a multitasking interface. Build your application in such a way that people can access more applications if they wish to, but just don’t make it visible at all times.
Evaluation
In the pictures I’ve posted, I indicated that a gripping and dragging motion is required to perform the action (which in this case is launching an application).
Now, how I would approach viewing and launching a different application from the camera button is to just swipe left or right over the button area. I’d remove the tapping action since the drag up is the default method and allow the user to scroll through the applications they allowed onto the lock screen one at a time. It will be a continuous cycle so if you hit application number five, it cycles back to the beginning. Dragging up with the gripper on the icon of your choice will launch that application.
One question that might come up is “why are there no page dots?” Because there are only truly five applications available to you, there’s no need to indicate the page you’re on. Only one application is viewable at a time so there’s no confusion. Also, in Settings, you would be able to decide what order the applications fall into. Both of these points lend strong credibility to my choice of not putting page dots.
Conclusion
If you want to give this a shot, go for it! If you see something like about this and want to incorporate it into what you already have, go for it! Let’s strive to make our applications, especially ones regarding application launching from the lock screen, as native, user-friendly, and Apple-like as possible.
-Josh
© 2012 Joshua Tucker
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.
-Josh
Twitter: Joshua Tucker, John Heaton
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!
-Josh
Twitter: @joshmtucker, @gojohnnyboi
© 2012 Joshua Tucker
This is revision three for the interface I’m working on. In the process of designing what I had in mind, I drifted away from what I’m really aiming for in this concept. I haven’t really expressed it either so here’s my goal and vision for this interface concept:
Mission Statement:
To create a seamless, user intuitive interface with access to all of iOS’ core features that can be viewed with one unified action or gesture.
———————————————————————————————————-
Going back and re-thinking how I wanted to go about this, I changed a lot of things (as you can see from the pictures). Although I didn’t feel like I was rushing, I’m nonetheless going to take my progression a little bit slower so that I get a level of in-depth development. I appreciate all the suggestions and feedback you’ve given me so keep it up!
Before I move forward with the explanation of this revision, read up on my previous work to get some background. They are of the past now, but it’s good to get some well-rounded information about my progression.
Oh one last thing: Here are the assumptions I made when building this concept:
- To achieve the seamless nature, the interface is an overlay over a blurred image of what’s in the background (wherever you came from)
- No matter where you are when in this interface, all the features work and are useable.
- This interface is accessible everywhere except the lock screen (for security reasons — manage lock screen notifications with this concept).
———————————————————————————————————-
Activation:
Activating this interface could really be anything, however the methods that I’ve chosen for this interface are:
- Double tap Home button
- Swipe down on status bar
To get out of this interface, you can tap the Home button twice again or swipe up from the bottom of the shade.
In iOS 5, the way you access the Notification Center is by swiping down from the status bar while accessing the App Switcher is done with a double tap of the Home button. Since this interface is unified, you’re able to access both while within the interface. However, the starting page can be different depending on what you do. Here’s how I have it working (conceptually):
But first — note that the App Switcher interface I’ve designed is a merge between launchpad and multitasking functionality. It will be explained in more detail farther below.
- Double tap Home button — It will bring you to the App Switcher/launchpad interface first. From there, you can move from page to page
- Swipe down from status bar — You start off at the Notification Center. From there, you can swipe to get to the App Switcher/launchpad page
Note: In terms of the page dots, the Notification Center is the first dot and the App Switcher/launchpad page(s) are after. The number of dots varies on the number of pages you have on your App Switcher/launchpad.
Pages:
The page you’re on is noted by a page dot. To get to other pages, simply swipe left or right like on the SpringBoard.
When on this page, you not only have access to what applications are multitasking but also applications that you can launch. The page(s) that pertain to App Switcher/launchpad are organized from top to bottom starting with applications that are multitasking (most recent first). After that, they are organized in alphabetical order by default. The layout of the App Switcher/launchpad isn’t based off of what your SpringBoard looks like. You can make it the exact same if you want to our change it up however you wish. Putting applications into folders works in this interface just like on the SpringBoard.
Two Notes:
- To restore to the default alphabetical order for this interface, there will be a reset button somewhere in Settings.
- You cannot delete applications from this interface. That is all done through the SpringBoard like default.
You can at anytime arrange the icons however you want by going into Wiggle mode (holding down on one of the icons). When in Wiggle mode, applications that are multitasking will be distinguished by the default minus button which will allow you to quit the application out of the background if you wish to.
Note: My design incorporates my multiple icon mover concept (outdated but the premise is the same. I’ll at some point go back and revamp it to match this interface)
Notification Center:
The Notification Center is another page that is directly accessible from this interface. You can move to this page at any time as well as start on it (read above under the Starting Page section). And of course, you can move to the App Switcher/launchpad interface from here by swiping to the respective page.
All the normal functionality of the current Notification Center (managing notifications and what not) applies here.
Note: There are components of my older Notification Center concept will be incorporated eventually (outdated but many of the parts apply to this).
Spotlight:
The Spotlight feature is definitely a staple a component of this interface. It is taken to a new level because it is available no matter what page you’re on. Swiping between pages switches content below the Spotlight header but never hides it. You always able to access and utilize its functionality.
———————————————————————————————————-
Here is my checklist for this concept as of now
- - Review what’s already done and tweak accordingly
- - Incorporate music/rotation lock controls
- - Work with the Spotlight feature in more detail
- - Add important toggles
- - Elaborate on the quitting applications functionality (individual and multiple)
- - Put in multiple icon mover functionality (or I should say demoed with this interface)
———————————————————————————————————-
The first draft reveals the art, revision reveals the artist.“ - Michael Lee
© 2012 Joshua Tucker
This is my concept on a Downloads section in the App Store.
Accessing the List:
To get to this list, simply go into the App Store, navigate to the Update tab and than hit “Downloads.”
Note: If you go to the Updates tab now, it has the Purchased tab. Right below it will be a downloads section (haven’t designed it yet).
How it Works:
This scenario applies for two different situations:
- Buying an application
- Installing updates of applications already on your SpringBoard
Note: This also goes well with my App Store lists concept.
If you do any of those options, it will take you directly to the download list. It will show the following:
- The application(s) that is (are) installing
- The amount of time it will take (based on connection speed)
- Paused downloads (if applicable)
- Progress bar
From this section, you can do the following:
- Pause a download (hit the pause button on the far right)
- Resume download (if it is paused, hit the reload button to revive the download)
- Remove the download (swipe right and hit the “Remove” button)
After it brings you to this section, you’re welcome to freely move through the App Store and you won’t get booted out like you normally do. You can also exit the App Store if you wish and come back to this list and check up on your downloads.
Pause, Resume, and Remove All Buttons:
The names give it away but here’s what they do.
- Pause All - will pause all the downloads (if you check your SpringBoard the application in question will reflect that with the “Pause” indicator)
- Resume All - will resume all downloads (check your SpringBoard and you’ll see the applications download again)
- Remove All - will stop and remove all downloads (removes icon from SpringBoard if applicable)
These three buttons float under the last download in your queue. So in this case, it is visible when you enter the Downloads section. If there are more applications than the view can show, you simply scroll to the bottom to have access to these buttons.
———————————————————————————————————-
This is what I’m looking to add to this concept:
- A badge on the status bar that lets you know how many items are downloading
Stay tuned!
———————————————————————————————————-
“A life spent making mistakes is not only more honorable, but more useful than a life spent doing nothing.” - George Bernard Shaw
© 2012 Joshua Tucker
This idea stemmed from my recent lock screen dial code concept. Read the the first dial code concept to get information on the security measures for an application like this.
Basically, this will allow you to lock applications so that people can’t use them arbitrarily.
Dial Code:
You set the code somewhere in settings (have no idea) and then set it to the applications you want. If you open an application that is passcode locked, instead of it asking prior to opening, it will stop you at the loading screen. At the bottom, a dial code will appear. Put in the right numbers and you’re in!
Note: I may change it so that this lock appears on the outside prior to opening the application however I haven’t gotten that far yet!
Happy New Year!
© 2012 Joshua Tucker
