For all my Twitter followers who replied or saw my post, I polled all you guys on the following question:
#Poll How do you most often end a phone call?
A) Use the “End button”
B) Use the Power button
The reason why I asked this is because I wanted to point out an interesting inconsistency with the Power button while in a phone call and discuss my solution for this issue. You can test this out for yourself and see exactly what I’m about to tell you.
If you’re in the Phone application and currently in a call, there are two ways to end a phone: using the “End” button or pressing the Power button. However, if you exit the Phone.app and come back, the Power button locks the screen instead of ending the call.
I’m someone who accidentally hangs up a call by putting my phone to my face and it hitting the “End” button (I’m sure many of you have experienced the same thing). The way that I keep myself from doing that is to lock the screen. But, it’s not an action that can easily be done. I have to multitask and do something else in order for the Power button to “switch” over to locking the screen instead of ending a call. The inconsistency of the Power button makes it difficult to remember what action will be done.
Since the Power button’s main use is for locking the screen, no matter where you are or what you’re doing, I think that it should be reserved for locking the screen only and not ending the call. For those users who use their Power button to end a call, I would say that there could be a short hold in order to end a call with the button so it’s not confused with simply locking the screen.
© 2012 Joshua Tucker
Now that iOS 6 has pull to refresh in Mail, the refresh button has been removed from the bottom bar. Being someone who always tries to find ways to utilize “dead space,” I thought about something that I would like to have easier access to from that view.
One area that’s difficult to get to in Mail is the folder hierarchy for each account. In other words, you can’t easily navigate to another folder within your account (inbox) very easily. The process to do that now is to go to the main page of Mail and go into one of the Accounts at the bottom of the list. That’s displacing if you’re already in the inbox view.
To make the process easier, I brought a folder button to replace the refresh button inside the inbox view. If you tap that folder icon, it will bring up the hierarchy view and allow you to switch to another folder right from the inbox view. If you have more than one inbox and are in the “All Inboxes” view, all the folders for all accounts will show. But if you’re just in an individual inbox, it will only show folders from that inbox.
You can always quit out of the view and return to the inbox you’re in. Easy peasy.
P.S. If you want an invite to Branch, click this link and “Ask to join.” Come discuss this concept with me there!
© 2012 Joshua Tucker
With cell providers continuing to cut back on data and increasing the prices of the plans, it’s crucial to be aware of how to limit your data usage. Push for Mail is a core component of iOS and is extremely useful, except when it eats into your data. You want the capability to have push, but many of us have to disable it due to our data usage habits. However, many of us are in areas where Wi-Fi is available often therefore we aren’t concerned. But at this point push for mail is either an on or off option. And when it comes to Fetch, same deal - possibility of increased data usage.
I propose that an easy solution for this issue would be to allow the user to specify whether push or fetch uses cellular network. In the first picture, note that a new toggle would be added allowing you to decide whether push (if enabled) and fetch uses cellular data. The next following pictures show the options you would have if you go into the Advanced section and select a specific account. If you select either Push or Fetch, it will offer you the option use cellular data for that specific account only.
Hit me up on Twitter with any questions or comments. Or feel free to post below.
© 2012 Joshua Tucker
The heart of usability goes after the user. From a user interaction standpoint, the purpose of such design is to enhance the environment allowing each and every user to experience it in a simple, native, and unique way. To accomplish this, problems must be solved. Just a like a developer solves a problem through code, a usability designer solves a problem through design and interaction.
I’m writing this post as I feel its important to stress that to accomplish excellent usability, you have to approach the environment taking in a 360 degree view. What I mean by this is, many times developers and (or) designers bring out this great awesome new feature or interface but don’t account for the other existing factors that are inadvertently “removed” or “hindered from use” due to how the implementation is done. Also, solving one problem doesn’t mean you solve them all. Introducing something new is great but can cause problems in the interaction itself by offering a limited field of usability.
I’m going to use the following example to illustrate my thoughts and conclude with how I feel this scenario applies.
Search Engines in Safari for iOS versus Search Engines in Safari for OS X
Safari on OS X has had a slick feature for a while that allows the user to change the default search engine right from the search field. Now that Safari has a unibar designed (part of Mountain Lion), it’s now done through the address bar. When the URL field is empty, a magnifying glass will appear on the far left. Clicking it will drop down a small window and give you an option to switch to another search engine in the list. Clicking a new search engine will change the default search engine. The default search engine can also be set in Safari’s preferences.
With the way OS X has it set up, it would be easy to gradually add new search engines to choose from because they are easily accessible from anywhere. Even though a user may switch often, it’s excellent usability to allow the user to switch at anytime without going through dialog windows, settings, or by doing numerous steps. Convenience is key.
On iOS, it’s much different. The way you can switch search engines is to go into Settings > Safari > Search Engine and change it. And technically, by doing this you’re doing two different things. First, you’re changing the default browser. Second, you’re changing the search engine you wish to use in a session if you’re currently browsing. What I mean by this is, if I want to switch to searching Bing in my session from the search field, I’d have to switch my default engine in Settings so that I can. The way iOS has it setup would make it extremely difficult to continue adding more search engines because it’s difficult for the user to switch them quickly within the current view. Again, convenience is key. Having the ability to switch search engines from within Safari is key.
When it comes to searching the web, I feel that it’s extremely important to have “liquid methods;” actions and tasks that can be done dynamically right where you are without having to pull yourself away from the current view. Switching search engines I think is one of them. OS X has got this covered, so how could iOS improve? Here’s my solution. Give Safari in iOS a unibar design. Offer the magnifying glass icon on the far left and allow the user to switch simultaneously right in Safari without having to go into Settings to switch it so it can be done natively within the address bar.
So the natural follow-up question would be “how does the scenario above apply to a 360 degree view of usability (or initially the point of this post)?“ This scenario gives an example of offering a feature that may not necessarily be “user-friendly” in all cases. The problem being solved was the fact that users need a default search engine option. The solution was offering a way to offer a setting to set the default search engine. But, to my point about a continued 360 degree spectrum, another problem arose. The next logical step became “I’ve given them more than one option for a search engine but what about when they want to switch search engines easily?” OS X allowed the user to switch dynamically. iOS hasn’t followed in its footsteps yet.
Problem solving is a process. Solving one problem doesn’t solve them all. When thinking of usability and interaction design, remember that it is on a 360 degree spectrum. Features, actions, methods, and tasks all loop around and interconnect with one another. To be cliche, the quote the expresses it in the most down-to-earth way would be “What goes around comes around.” So when introducing something new or changing something existing, take this approach and look from a bird’s eye view of how your project, application, or tweak will offer something unique as well as how it will potentially shift how other things work. Follow the trail all the way around making sure each step of the process is simple and user intuitive. And when you reach the other side back to where you started, you know you’ve created something amazing.
© 2012 Joshua Tucker
This project is in progress.
NOTE: I know there is an application in Cydia called Pull To Refresh Safari that has functionality similar to what I’m proposing below. I explain why my implementation is different.
I have discussed in the past that my view on pull to refresh is somewhat unorthodox. The convenience of pull to refresh is great, except I feel that it displaces what you’re doing. You have to be at the top of the list, which means you have to scroll back up. That can disrupt what you’re reading or viewing because you want to see new content. But it’s a gamble because if you go through the trouble of refreshing and nothing comes in, you now have to track back to where you are.
As much as people say “Well finish what you’re doing first,” I don’t think the average human brain thinks that way. It’s darting around looking for things to do. And when it comes to content, you’re always wanting the newest and potentially more important showing as soon as possible.
So when it comes to pull to refresh, I want the following things with it:
- The ability to pull and refresh (obvious)
- Being able to pull and refresh and remain where I am in the scrollable view
In pursuit of my goal, I decided to tackle Safari on iOS first. I can imagine that other people share my same view so I made sure to be thorough on how I felt this implementation would work best. My concept below allows me to do both of those objectives above. It is broken down into four sections for your reading convenience.
1) Pull to Refresh Text and Handle
I put this as a placeholder for my concept. Due to the fact that iOS 6 is still in beta, I refrained from using the new pull to refresh symbol that is used in Mail. Therefore, this section is short and sweet. This portion will use the same “gear” as what’s in Mail on iOS 6.
2) Linen Background
If you pull down the view now in Safari, it has a darkish background. I felt that this wasn’t an appropriate color for the pull to refresh view so I used linen instead, which resembles the view that is shown on the iPad when you pull down in a Safari view. The linen also brings in some familiar iOS portions which collectively syncs the entire experience together.
3) Address Bar
To ensure that I can’t be displaced from where I am on a page to refresh, I designed the address bar to handle as follows. The address bar will remain static (in other words it won’t ever move) and content flows under it. If you can think of in Mail when you’re scrolling through emails, the list slides under the header? That’s how it would work.
But, it comes with a cool twist. When you scroll down, the header will hide. To make it re-appear, you just begin to scroll up. If you’re in the middle of the page and start scrolling, content will flow underneath the header until it reaches the top of the page. The whole time the address bar will be locked at the top to the status bar. Another cool feature is that if you scroll and you don’t actually reach the top of the page, the Address Bar will auto-hide after inactivity (scrolling up only).
Now here comes the pull to refresh part which I feel is unobtrusive and convenient. To pull to refresh, simply tap the address bar header and drag down. No matter where you are in the view, the whole window will come down showing the linen and the symbol to pull to refresh. After you complete the refresh, it will refresh the page and bring you right back to where you were on the page before refreshing.
4) The Window (or Page view)
The significance of this portion is that the view is independent of the pull to refresh. Since the content slides under the Address Bar header, it won’t conflict with pull to refresh.
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
This concept showcases an enhancement to folders on the SpringBoard to allow the user to switch folders without having to leave the folder at all. To move to the next folder (left or right), simply drag over and the content in the next folder over will come in; similar to how you switch pages on the SpringBoard. The user can move as many folders as he or she wishes by continuing to drag after the folder ahead of it in the queue is fully loaded (again, like how SpringBoard manages paging).
I broke down the fullscreen image into six sections to document how the implementation works.
1) The folder you’re switching from and its label
As you switch to the next folder, the following things happen. The folder itself with its respective icons begin to fade out to match the opacity of the rest of the icons on the SpringBoard. Since the label for the folder that is being switched from is gone when in the folder is open, that label begins to fade in to the level that the rest of the labels are. In this case, the folder “Misc” is fading down while its label is fading in.
2) The folder you’re switching to and its label
This works in the exact opposite of the above. The folder you’re switching to fades into to full view while the label fades out until it is hidden. In this case, the folder “Apple” is fading in while its label is fading out.
3) The dialog arrow on the folder
The arrow plays a key role animation-wise to distinguish that you’re switching folders. As you begin to move one direction, the arrow follows along along the horizontal axis attached with the top of the folder. As soon as it reaches the next folder, it stops. Like the SpringBoard, if you don’t page far enough and let go, it will go back to its original position. If you scroll far enough and let go, it will continue on its own until it hits the next folder.
4) Folder label of the folder that’s coming in and the previous folder’s label
When switching folders to the right (as depicted), the folder you’re leaving starts heading off to the left. The icons head out and the label follows them as well. In the case of this example, the label is already gone because it is on the far left side when displayed normally. If you switch the opposite direction (not depicted), then the label stays shown as you move into the next folder until the new folder takes view. As soon as the other folder is loaded, the previous label is already off screen and out of view.
The incoming folder works the same way. The label follows the icons in and how the label is viewed depends on the number of icons in the incoming folder and which direction you’re coming from.
5) Incoming folder icons
Briefly mentioned above, the icons come in from whichever direction you’re switching. The incoming icons push the previous icons out and don’t fade or perform any animation. Think SpringBoard paging.
6) The folder canvas and other SpringBoard icons
Because the folder canvas changes size based on the number of icons in the folder, the canvas will change size dynamically as you move into the next folder if applicable. That means it will grow larger or shrink smaller as you move into the next folder.
Since the SpringBoard icons (the low opacity icons) change layout based on the size of the canvas, they will move down or up depending on whether the canvas is getting smaller or larger. It will follow in suit to whatever the canvas does. In this case, you can barely see a row of icons poking off the bottom of the screen. When this animation finished, that third row of icons will be visible with the folder “Apple” displayed.
Here are some answers to a few possible questions that you guys might have.
Does this functionality conflict with the native folder handling?
No it doesn’t not. It’s an enhancement. You can still leave folders and go to the SpringBoard or another folder if you wish to that way.
How does this implementation handle switching when the next folder is on another page?
If you switch to to another page, it will simply jump to the next folder and keep the same animation style (which includes the dialog arrow moving into position if applicable)
Will this implementation work on all iOS devices?
Yes it will. Although depicted on the iPhone, the folder-switching capability will be usable on the iPad and iPod touch.
Any further questions can be posed to me on Twitter or in the comments below.
© 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.
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.
Individual management of notifications is a vital component of Abstergo. Simple. Concise. Elegant.
Note: Images are not live screenshots. The elements depicted are what will be apart of it. Anything and everything is subject to change.
There’s still much to do, but the time grows ever nearer. Are you ready?
© 2012 Joshua Tucker