UX/UI Design, UX Research
ARGON: Augmented Reality Browser
AR browser is a very popular way to implement AR technology on mobile phones for its splendid cross-platform feature. Distinct from traditional Web browsers, AR browsers (e.g. Layar, Junaio, Aurasma, etc.) utilize the camera view of smartphones to create a unique visual-tactile interface, which blends a person’s gaze of the physical environment with texts, graphics, and other media files. Some of these data are “geotagged” to specific geolocation on the Earth’s surface. Another way is to make use of computer vision and image tracking software, creating a more precise mode of aligning digital overlays on top of print media, building facades, signage, and other fixtures of the built environment. These AR applications, which are built in AR browsers, provide another angle to get expanded information about the physical world and try to bring AR technology to more and more people with smart phones.
Though existing AR browsers have allowed people to prototype and build simple examples, it is hard to go beyond that. To give people the full power of the Web, and not be limited to the simplistic APIs of those browsers, Argon is created.
Argon is an open-standards web browser with augmented reality capabilities, which means that you can use it as other mobile browsers as well as AR browser. It is developed and still under developing by AEL (Augmented Environment Laboratory) in Georgia Institute of Technology.
Problems and Goals
Though sharing some similarities, the interface of Argon is not exactly the same as the common web browsers. It currently uses the camera view by default and there are only very basic functions embedded.
The functions include URL input, refresh, switch to reading mode, full screen, bookmarks list, add a new channel, switch to a specific channel, and add bookmarks.
While the development of Argon.js, relevant tutorials/documents, and the browser itself is moving forward rapidly, some problems related to either usability or user experience are still left there to be solved. The unbalance between two sides makes the need to improve the usability and user experience becomes more and more urgent.
The main problems are ternary:
1. Lack of necessary functions
Some key functions, which should be included in a mobile browser, are still missing.
2. Usability problem
For now the browser cannot fully support the users to perform the main tasks. Many of the functions are difficult to use even for the developers themselves.
3. User experience problem
The application is currently not designed for common users, but more for the developers. It is almost impossible to utilize it to fullest without others’ guidance or related background knowledge. It is technical, but not user friendly enough.
We have three types of users:common users, developers and other stakeholders. For this redesign, we will primarily focus on the type 1 users. The reasons are listed below:
• The goals and usage of Type 2 and 3 users are based on how the type 1 users use the system. The usability and user experience for type 1 users should be the first and essential concern;
• The existing system is already having type 2 users and some type 3 users, usability and user experience problems are more obvious for type 1 users and relevant feedback, data and research are lacking;
• The user group of type 1 users will be the biggest among all 3 types.
After user study, I built a persona to represent type 1 users:
Maggie Smith is a 23-year-old college student studying Business at Georgia Tech. She has an iPhone 5 and carries it everyday with her. She uses it to make calls, sending iMessages, and check Gmail. She is also a social network person: She uses Facebook, What’s App, Twitter, YouTube and Instagram with her iPhone a lot. Her close friend Sandy, who is a second year MS-Electrical Engineering student, tells her that there is a very cool application named Argon and she should check this out. So Maggie plans to download the App and make it work, maybe she can share what she sees with Sandy afterwards.
Because Argon is a mobile browser with AR capabilities, we do compete study on both mobile browser side and AR browser side. Therefore, these two parts can compliment each other.
To better understand the capabilities and information structure of current most common and popular mobile browsers, we look into the functions and layouts of Safari mobile, Mercury, Dolphin, Chrome mobile and Opera mobile. And the technique we are using here is mind map.
In terms of functions and features, those popular mobile browsers obviously share similar function sets: navigation around multiple websites, navigation based on the current page, settings for the browser or relevant account, bookmark system, URL input, usage of the current page.
Navigation around multiple websites: Switch between multiple running websites, open a new blank website, and close a running website.
Navigation based on current page: Go forward, go back, and refresh.
Settings for browser or relevant account: Change font size, brightness, themes, full screen mode, notification, etc.
Bookmark system: Add bookmark, create bookmark folder, delete a bookmark, rename a bookmark, change the location of a bookmark, and retrieve history.
URL input: Clear URL box, auto-complete, and search.
Usage of current page: Add to home screen, add to reading list, share and print.
About the layout, they follow a fixed pattern of putting URL input onto the top of the screen. However the differences show up when it comes to other functions. While Chrome and Dolphin place the current page related navigation onto the top, other three browsers choose the bottom bar. And though most of the browsers use bottom bar, which has relatively larger space left than the top bar, to place other functions, Chrome utilizes a menu button on the right side on top bar to contain its functions, which cleans up the bottom of the screen and makes users more focused while using the functions.
We have also looked into commercial and open-source AR browsers in the market such as Junaio, Layar, and Wikitude. They are called AR browsers because they are mostly for AR content display only and that is different from Argon. However, it is still worthwhile to refer to their layouts and functions design decisions.
Unlike the usual mobile browsers, AR browsers look basically simpler in terms of functionality and layout. They have several internal similarities: Search channel, camera view, recommendations, tutorials and settings.
Search channel: Because only specific channels can run within the browser, so the URL bar is replaced by a search bar or search function.
Camera view: The largest space on the screen is taken by the camera view, which shows the AR content from running channel overlaid on the reality.
Recommendations: A list of featured channels recommended by the systems, help users get started and see what is new.
Tutorials: A series of slides or websites showing users how to use the browser, it is necessary because AR browser work in a very different way compared to usual browsers.
Settings: A place for users to change the settings for the browser.
Both of Layar and Wikitude have favorite system, which is like a simplified version of the bookmark system of other mobile browsers. And because a considerable part of AR channels are working based on user’s geolocation, Junaio and layar notify the users of usable channels nearby, which naturally involves the users into a strongly relevant AR experience.
And about the layout, two of them are using left side bar with Breadcrumb menu instead of top bar. Because there are more AR related functions and sub functions to show and topside bar might not have enough space for them and their extensions.
Along with the data from the user study, the competitive analysis, the insights brought by Prof.Macintyre, who arouse the idea of the Argon browser at the very first place, Prof. Bolter and PhD student Gheric Speiginer, who has been working on Argon development for years, are the foundation for the functionality requirements.
In this approach, we learnt that the order and settings of running channels (websites) are extremely important and multiple channels will probably collaborate, complement each other to weave a decant AR experience, Argon should have more controls over running channels (websites) and capabilities to inform the users of the current status.
• Management of running channels (websites).
• Indication of running channels (websites).
• Multiple mode switches for channels (websites).
• Navigation around multiple websites.
• Bookmark system.
• Settings for browser or relevant account
• URL input
We generate usability and user experience requirements from previous interview as well as lab meeting.
• Learnability and understandability
The application is intuitive, easy to learn and do not require related background knowledge or experience of the user. It can work and show its capabilities in the shortest time for new users.
• Efficiency (short workflow)
All the fundamental tasks have a short workflow. None of them is time-consuming.
• Easy to use
All the fundamental tasks are easy to perform with low physical and mental efforts.
• Simple layout
The layout of the interface is clean, simple, and easy to look at and make sense. No function cluttered or information overload.
• Torrance for error
It is safe for users to explore within the application; they can always undo or cancel their action when they want to. No irreversible impact will be made during the exploration.
User experience Requirement
• Visual appearing
The interface design is aesthetically appealing to the users, and follows the design pattern of iOS platform.
• Consistent to GT and AR technology
The color and style of the application are consistent with GT Visual Identity Guidelines and match with AR technology theme.
• Smooth interaction
The interaction is smooth and makes sense to the users. They match with users’ expectation and previous experience.
• Positive emotional feedback
The application rouses users’ positive feelings such as confident, satisfied and relaxed.
Design and Iteration
I went through 2 rounds of sketch iteration and 4 rounds of prototyping iteration. At the end of each iteration, I asked the professors and developers in my lab, as well as my designer peers for feedback.
We recruited 15 students in order to have enough subjects. Based on previous research in this area, this size is considered appropriate for this kind of study. Participants are between 18-40, mentally competent, English speaking and smart phone users.
Participants who are not using smart phones or using smart phones only for texting and calling (not using mobile applications frequently). Because they may not be the potential users.
To check the outcome report, click HERE.
Analysis and Future Work
The problems we should fix here are mainly:
• The idea of start page and reading mode is unclear;
• Consistency issue;
• The way to control indicator is not intuitive;
• Visibility icon/font (size, contrast, hidden);
• Gesture for closing channel.
• Overlong process of favorite;
• Not having shortcut to full screen mode;
Ease to use:
• Accessibility of icons (size).
• Too many panels working at the same time;
• Indicators may be distractive.
From the research we got some insights to guide further design:
• Browser should be able to make use of as much part of the screen as possible to show channels;
• Powerful indicators are needed to show the data users want to know;
• Map Argon Functions to common browser in terms of layout, icons, and function;
• Intuitive and understandable is more important than shortcut and short process right now. Long process is ok as long as each step can come across to the user. Shorter process does not make sense if the user cannot make sense of it according to their experience and expectation;
• Onboarding process is needed for new conception and features.
• Use Home icon for the start page and include an introduction of start page in the onboarding process;
• Move current notification function into settings or channel management;
• Place the add bookmark button beside the url bar;
• Include an introduction of reading mode in the onboarding process;
• Change the icon set for mute/hide channel (not use color to show status);
• Make sidebars (left and right) to take the whole screen;
• When user adds a bookmark, a popup asking whether to favorite it;
• Make icons bigger;
• Keep the two icons for adding a new tab consistent;
• Add background to the URL bar;
• Make indicators (notification, overview mode) bolder;
• Use ‘AR’ as the icon for disabling reading mode;
• For the first time launch the application, floating text explaining the main functions (start page, bookmarks and recommendations);
• If there is no data coming in, the indicators disappear automatically;
• New function to share website on social network;
• Swiping for closing channels.