Smiley face
UI Design of Argon
UX Design for Argon, an Augmented Reality browser
Introduction to AR, AR browser and Argon

Augmented reality (AR) is a no longer a curious term nowadays, and AR technology has come into the everyday lives of more and more people from labs and big companies.
At the same time, mobile devices develop at an amazing speed and become more and more functional and affordable, which dramatically increases access to AR around the world.

Different from specialized AR devices, such as AR glasses and AR helmets, mobile phones are more economical and accessible for most of the people. Also, people will carry them everyday, which makes mobile phone the most practical way to deliver AR; Though head worn and other AR devices have far superior performance in terms of both display and control when compared to smart phones, however, phones will still be an important AR platform for a long time.

And 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.

It is a native app currently running on iOS devices and its UI is written in JavaScript. Because three.js is very useful and popular library for creating visual objects and detecting real world. Argon is now providing an argon-three.js library, which is easy to use for the developers who are familiar with three.js. And it will provide more and more libraries eventually.

Problems to solve

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.

User and Requirements (Post-Design Research)
According to the interview with Augmented Reality Lab faculties and students, the users of existing Argon formally were basically developers and students, who work on creating websites with AR content and use Argon as the platform to design AR experience.

But this is far from what we expect nowadays, we want to involve all the smart phone users who are curious about new technology and want to view or work with AR content, and also stakeholders who want to benefit from exploring and utilizing the possibilities of this platform.

Primary users
1) Common users
• Smart phone users;
• Use smart phone for purposes more than texting and calling;
• Use apps from the app store;
• Have different levels of understanding of AR technology;
• Have or not have experience of using AR techniques before;
• Need to view AR content for entertaining purpose, personal tasks or work.

2) Developers
• Work on web development;
• Familiar with JavaScript, HTML and CSS language;
• Have some knowledge and experience of WebGL;
• Plan to develop website with AR content.

Other stakeholders
3) Organizations
• Want to show the augmented information of specific location/spot/product to guests, customers or their employees;
• Have database for all the information needed;
• NGO or Business based.

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.

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.

Competitive analysis
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.

Mobile browser

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.

AR browser

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.


Functional Requirements

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.

Usability Requirements

• 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 is 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.
User Interface Design

With widgets

Full screen mode

URL, refresh and bookmark functions placed on the top side bar just as desktop browsers. Content, which is the camera view, is embedded in the whole screen and users can tap on the content to hide the widgets. Basic navigation functions, reading mode, bookmarks page and settings are put in the bottom bar, which is similar to other mobile browsers. And when the users are viewing in full screen mode, swiping up from the bottom of the screen will bring the widgets back. And an indicator on the left top corner of the screen will inform the users the running channels and the types of their contents. Tap on it will bring the user to channel management screen.

Sketches (adv)

After sketching out the basic interface, we made advanced sketches or basical wireframes to start with in order to communicate. The user will begin with the first screen and see the reality via the camera with the top bar and bottom bar after launching Argon. And after inputting the url of AR website, they can see the real world with AR content overlaid on it. The user can tap on the indicator on the left top corner to open the fourth screen, which is channel management page, and change the order of channels, check detailed information of channels, create a new blank channel and delete channels.
And when the user taps on the reading mode button in the center of the bottom bar, the website will be shown in a normal way like be shown in any other mobile browsers, which means that camera view and AR content will go away.
The bookmarks system on the right of reading mode button, the user can check the folder he created and websites he bookmarked before and do basic managements such as move or delete websites and folders.

Prototype (Multiple iteration)

In the first round iteration, we just put what are in the wireframes into Sketch, making them look more real. Then we showed these mockups to professors and development team in the Augmented Environment Lab (AEL) to get feedback.

During the 1st round iteration, we came up with another idea for showing basic functions: Using a floating wheel panel, which contains main functions and can be expanded. Users are also able to move the wheel panel around and leave it wherever they like.

However, when we double checked the requirement and found that needed functions are much more than what can be shown within this layout. And the developers addressed that swipe up from the bottom may arouse the iOS system settings, which means it will cause problems for hiding/showing control panels. In addition, the more gestures we take for UI, the less gestures are available for the AR websites run on Argon. So we began the next round of iteration.

In this version we removed the top bar and bottom bar to deal with the gesture collision problem, and used a left side bar as a control panel. Meanwhile, we added popular pages, about Argon and add new channels to the breadcrumb menu.

Another big difference is that now, we used an individual screen for opening a new channel, which resulted from taking the top URL bar away. And because we have a specific screen now, we are able to put some recommendation and frequently used channels here as a shortcut or quick onboarding for users.

Then from the Lab meeting, we got the feedback from faculty and interviewees that hiding URL bar in the main view is not intuitive to the users and users have got used to the fact that URL bar is always on the top of main screen. So that became the reason for the next round of iteration.

And there were also other problems: When there are a lot channels running, the indicator will fail to serve the purpose of notifying the users what is happening. There wouldn’t be much information shown about a specific channel because information such as file size won’t make any sense for most of the users.

In the 3rd round of iteration, we got the URL bar back in the main view. And we added a homepage for quick on boarding and shortcut to favorites. Also, we used the right side of the screen to place a set of indicators showing the status of running channels. These indicators can be hidden or fully expanded to a channel management panel. What’s more, we added a taking screenshot function for tapping and holding gesture, which will automatically hide all widgets on the screen and take screenshot.

However, in the feedback we learnt that the URL bar and left sidebar should be visible throughout the browser or users will probably have no idea how to bring them out and quickly switch between different pages.
Also the screenshot function won’t be that useful because it is deeply hidden and iPhone has a screenshot function of its own.
Additionally, ‘heart’ is probably not a good symbol for ‘favorite’ because actually it means that users emotionally ‘like’ something or think something is ‘good’. For this reason, start might be a better choice for favorite.

In this iteration, we nearly fixed all the problems mentioned in the feedback for 3rd iteration. We keep the URL bar, simplified left side bar there by default, a simple swiping gesture can pull the full left sidebar out with text description for the function icons. We also changed some of the icons to make them more intuitive. Last but not least, we made the whole design more visually appearing.

Interactive prototypes

To show how the structure of the prototype and generally how it works, we firstly make a rough interactive prototype with Keynote, which has basic navigation and animation functions.

Then we used a more powerful prototyping tool, Modao, to show more details, add more status, gesture controls and animations to make it more interactive for demo and gather feedback.

Finally, we utilized Axure and AxureShare to embed all the features we want to test with users into it and made it capable for next stage usability testing.
User Evaluation
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.

Test platform and Preparation
The prototype is built with Axure and will be test with AxureShare. We use a smart phone with camera to record the research and an iPhone with AxureShare to run the prototype.

-Screen record and Audio record: We use a Mac with QuickTime to record the screen of iPhone, which is the platform for the test. We use another phone to do audio record.

-Note sheet: We prepared note sheets [Appendix 3] for all 15 tests to take notes for different sections and questions.

-Consent form: We prepared consent forms [Appendix 1] for all 15 subjects.

-Pilot test: We conducted a pilot test with an AEL VIP group member and checked the preparation and process of the whole test.

-Storage of data: We used flash disk and Google drive to store the digital copy of both audio and video records. All the files are encrypted.
We used a sealable folder to store all the paper documents, including the signed consent forms and note sheets.

-Scheduling: We used When Is Good for scheduling with all the 15 subjects.

-Script: We prepared a detailed discussion guide for the test and even anyone who is not familiar with the test at all can make use of it to conduct the test and gather all the data needed.



Background survey
In the very first section, we decided to begin with asking subjects general and background questions to understand their past experience and knowledge of AR technology and in this way we introduce AR and Argon to them in a very natural way and also made the subjects feel relaxed and guide them gradually feel comfortable about our following tests.
First impression survey
At first we show the subjects with some screenshots of the new user interface of Argon. And ask about their first impression and expectation. In this way we are able to test the general feeling of their first glance at the browser. And also test the usability issue of the icons and layouts. Also, it happens us to explore the possibility of redesign the gestures and information architecture, even introduce new features based on their expectations.
Benchmark tasks
Benchmark tasks is a core section in the research. Subjects are supposed to perform three tasks using our high-fidelity interactive prototype, which runs on iPhone. In this way we are testing the potential usability problems of three key tasks of our application with specific provided scenarios: 1. Open/close a channel and navigation; 2. Usage of bookmark system; 3. Management of channel and UI control. We break the tasks down into steps and therefore we are able to look into the usability problems and functional problems in detail. The benchmark for completion ratio will be 100%, for guidance ratio will be 0%, and for the try times will be 1, which means the user only tries once and perform the provided task correctly.
Closing interview
We asked subjects their overall feelings of the prototype freely and their considerations towards a new application after the tasks. The purpose is to get a better understanding of the user experience provided by the prototype and inspirations of the direction we should work on and make progress.

Speak out loud protocol
In the benchmark task section, we encourage our subjects to speak out loud. In this way we can get a direct view of what they are thinking while exploring or performing a specific task. It helps us to figure out the usability problems that will probably be hidden otherwise.
Interview logging
We logged the interview sentence by sentence so that when we analyze the qualitative data. Therefore, we are able to understand the context of the viewpoint raised in a specific sentence, which is very important while generating insights.

Data visualization
We visualized the task related data to make better sense of the quantitative data gathered from the interview. We turned the task completion rate and guidance rate (if completed) into a bar chart and we can see clearly which tasks and steps are more confusing and difficult, which ones need more guidance. What is more, we leveraged the box-whisker plot to visualize the number of methods subjects have tried to perform each step, and it shows us which tasks and steps cost more tries to be figured out and which ones are intuitive and with less guessing.
Static analysis
Statistical analysis in this research is mainly for the benchmark test part. We worked on these three data:
1. Average task completion rate: Record whether the user completes the task during task session and calculate the average task completion rate for each task. The outcome lower than 70% will be checked whether the task is not set proper or any parts of the interface are confusing.
2. Steps and process Record the steps the user goes through when trying to finish each task and step. Match it with expected workflow. The more times the use tries, the worse learnability and mapping it has. This data will help us to rebuilding how the function works.
3. Whether the user need guidance to perform a task or step. It means the layout or information on that page is not understandable. We can focus on it and redesign according to user's feedback.
Mind map
We used mind map to make subjects’ sentences more organized and help us generate insights from tons of logs.

Outcome and Analysis
To check the outcome report, click HERE.
Conclusion and further iteration

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).
Simple layout:
• 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 startpage 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 add 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.