All posts in User Experience

Towards a Cleaner Firefox Startup

By On February 25, 2010 In Firefox, Next Version, User Experience With Comments Off on Towards a Cleaner Firefox Startup Permanent Link to Towards a Cleaner Firefox StartupPermalink

Notifications when Starting Firefox

What should happen when you start up Firefox?

Nothing. No notifications, no updates; nothing but a clean window ready to browse. This simple startup has been a goal for the Firefox user experience team for awhile (Faaborg has outlined our plan for eliminating startup dialogs here). As add-ons manager updates are among the worst current offenders, moving these notifications away from the startup process has been one of my goals in its redesign.

Why is it so important to make Firefox’s startup clean? The obvious reason is speed. Notifications and updates appearing and then requiring dismissal wastes valuable seconds. But there’s also interaction drawbacks when windows pop up. If a user is launching Firefox, he probably has a goal in mind, and that goal is unlikely to be updating his add-ons. By seeing an update notification, the user is being distracted from the task he wanted to achieve and forced to give some of his attention to a new task: dealing with or closing the notification.

Crashing Without Session Restore

However, what if we took this one step further, and didn’t try to automatically restore a user’s session after a crash? What if instead there was just one window, ready to go, with a link to restore the previous session?

Currently, if Firefox crashes once, the session restores when Firefox is reopened. If Firefox crashes twice in a short space of time, it’s assumed to be because of bad content from the session. That’s when Firefox throws its famous “Well, this is embarrassing” screen, and gives the option to restore the full or partial session.

This is fine in the expected case of the user crashing because of bad content and wanting to restore their session and get back to work. The problem is that forcing Firefox to quit, or deliberately crashing it, are increasingly becoming alternatives to quitting. Since websites often throw warnings before they close and stalling sites can mean waiting until a command can go through, it can be much faster to crash than quit normally. Here’s a couple ways this can go wrong:

Scenario 1:

Sally has 15 windows open, each with lots of tabs. A few websites she opened are starting to stall. Sally could wait until those pages resolve their issues, but her session is getting bloated and she really just wants to start over with a fresh session. Rather than wait for the stalling pages, Sally forces Firefox to quit. However, when she reopens Firefox, it tries to restore the session she doesn’t want. Sally quickly forces Firefox to quit a second time. Now she has the new session she wanted, because Firefox assumed her two crashes were due to bad content bringing down the browser.

Scenario 2:

Oliver’s first date with Annah is going great, and she’s come back to his apartment. Oliver knows the way to win her over is to show her that hilarious video with a cat falling down stairs. Annah sits down with Oliver at the computer, and Oliver goes to open Firefox. But, he hesitates. The last time he used Firefox, did he quit the browser normally, or did he force a quit, or did he crash, or did he turn his computer off? If it’s any of the last three, his last browser session will automatically display in front of his innocent date. Oliver isn’t sure he wants that. He opens Chrome instead.

If we give a link to restore a session rather than restore it automatically, Sally can use crashing the browser as a way to get a new session and Oliver can ignore his last session and watch his video.  When someone actually crashes they only need to click once, and they’re back where they started.

Herdict and its Tasty, Anonymized, Aggregated Data

By On January 4, 2010 In data, Features, Firefox, User Experience With Comments Off on Herdict and its Tasty, Anonymized, Aggregated Data Permanent Link to Herdict and its Tasty, Anonymized, Aggregated DataPermalink

Nothing sucks on the web like not being able to go to the site you want. Page not found and 404 errors are an inconvenience that entirely halt your workflow. What’s worse than not being able to access a site is not being given relevant information to fix the problem. When users are presented with an error message, they tend to do whatever will make the error go away to get back to their task. Page not found errors can’t be dismissed, because they’re shown instead of the content wanted.

What creates an added level of frustration is not being given information on what the problem is. When users get a Page not found error, they likely have two questions in mind:

  1. Is this problem on my end, or not?
  2. If the problem is on my end, how can I fix it?

These are questions that have been hard for browsers to answer. Currently, Firefox’s network error pages aren’t incredibly useful. They’re certainly not as useful as Chrome’s, which use Google Link Doctor to find possible matches both for subdirectories and domains. That won’t necessarily tell the user if the problem is on their end or not, but it will help if the problem is a typo.

So how could a browser tell users if the problem is on their end or not, without infringing on their privacy? One project that currently takes a stab at this is Herdict, which Johnathan Zittrain’s been working on at Harvard University’s Berkman Center for Internet and Society. What Herdict does is let computer users tell the “herd” – via a Firefox extension – what sites are accessible. The aggregated data can tell if a site is down (because no one can access it), or blocked by a firewall (because only some people can access it), or likely on the user’s end (because everyone else can access it). Not only does that answer the question of “is this problem on my end,” but it may start to answer questions like “is this problem only experienced by my country, network provider, or device?”

Useful stuff! Does it have a place in the browser, and specifically in Firefox? I think that getting and submitting anonymized data should have an increased role in the browser, and especially where it promotes transparency and information to the user. Mitchell Baker has been writing about data, and how Mozilla could be treating aggregated, anonymized data as a public asset that should be freely available. Especially in situations where sites are being blocked and censored, giving users knowledge of the situation seems to align with Mozilla’s goals of transparency and viewing the web as global public resource that must remain open and accessible.

One way something like Herdict could be incorporated is through those Page not found errors. If there were an option on these to submit anonymized data, we could build a pretty accurate view of accessibility information for a website and share it. Allowing users to submit data when there’s a problem is something many programs do already – especially for crashes. This is good design; it makes users feel better by registering the annoyance they feel as a useful data point to developers. Here’s some sketches of what it could look like to incorporate Herdict’s aggregated accessibility data with these error messages:

1. No available information on a site:

2. Site is blocked due to local firewall:

3. Site is down for a country:

4. Site is down for everyone:

Relocating Firefox’s Add-ons Manager

By On December 3, 2009 In 3.7, Features, Firefox, User Experience With 34 Comments Permanent Link to Relocating Firefox’s Add-ons ManagerPermalink

In my last post, I described some of the ways that we’d like to improve the add-ons manager. First, we’d like to fix some of the add-ons manager’s usability problems, such as confusing installation processes and distracting notifications. There’s also some new functionality that the add-ons manager needs to provide, such as better information about add-ons and incorporation of newer projects such as personas. It was clear from the feedback that developers as well as users would like to see the maintenance and configuration of add-ons become easier.

The Add-ons Manager as a Tab

The current add-ons manager window sometimes gets in the way (with apologies to Gizmodo)

A few commenters on my last post highlighted problems caused by the add-ons manager being a separate window. It can get lost among other windows, be as distracting as a pop-up ad when giving a notification, and means part of the browser UI being modified is obscured. A potential solution that I think addresses these well is moving the add-ons manger into the content area of the Firefox, so that it runs in a tab. Here’s a few benefits this design provides:

  1. Gives more screen real estate to the add-ons manager. This would allow enough room for useful add-on information, scanning an entire add-ons inventory, and functionality like add-on preferences.
  2. Presents a less fragmented browser experience. Firefox’s chrome is basically a frame in which users go about their online life. But to modify that frame, users have to jump outside of it and onto a floating window. Modifying add-ons in the content space means the user never has to leave their tabbed browsing. Also, they can see all changes their add-ons make rather than having those changes obscured by a window.
  3. Allows for a similar add-ons experience across different devices. Running the add-ons manager in a tab means that an internet-capable device does not need a separate window or menu to modify add-ons – any device which can open a window can use add-ons in the same way as a desktop computer. Add-on management on mobile devices, tablet computers, and fullscreen mode would all provide the same experience. This is a huge win as the web becomes less about the device it runs on and more about the user, who may access the web on multiple devices.

Designing such an add-ons manager is a challenge we’re actively engaged in. The final design must feel like it’s a part of Firefox rather than a website, even if it’s displayed within a tab. It must also be unspoofable. Below is a rough wireframe of the design direction that we are considering.

Redesigning Firefox’s Addons Manager

By On November 23, 2009 In Features, Firefox, Uncategorized, User Experience With 52 Comments Permanent Link to Redesigning Firefox’s Addons ManagerPermalink

When I ask Firefox users why they love Firefox, the answer often isn’t because of Firefox. Rather, it’s a particular Firefox add-on that provides functionality that has become invaluable to users. From developer add-ons like Firebug to social add-ons like StumbleUpon, a single add-on can fundamentally change how users interact with the web.

Firefox users get starry-eyed when describing their favorite add-ons

The reason add-ons are so important is because they are a fundamental way that users take control of their online life. Firefox touts its customizability as one of its main selling points, but users’ ability to customize their browsing experience is dependent on the talent and creativity of the add-on developer community. I’ve written in the past about the importance of Firefox providing a user experience ideal for as many people as possible right out of the box, without add-ons installed. But each user is truly unique and uses the web in increasingly different ways. That’s why it’s so important that add-ons be trivial to find, install, and begin using.

The Current Add-ons Manager

Add-ons are currently installed, maintained, and configured via the add-ons manager in Firefox. This window, found under the Tools menu, provides an inventory of installed add-ons and allows users to update, install, remove, enable, and disable them.

The current add-ons manager works, but could use some love

The add-ons manager has been largely unchanged since 2007, and it badly needs a redesign. One reason is that it has several usability problems that would provide significant benefit to users if fixed. For instance, the process of updating add-ons is currently characterized by interrupting important tasks such as startup. Locating a particular installed add-on currently involves navigating through categories such as extensions and plugins. Even experienced users I talked to find the distinction between these categories hazy. A redesign to address current issues should insure that installing and updating add-ons is trivial, notifications are non-disruptive, and the interface provides clear information about the state of a user’s add-ons.

However, a successful redesign of the add-ons manager must not only fix problems, but add functionality. This is because the scope and functionality of add-ons has increased dramatically and will continue to expand in future versions of Firefox. The current add-ons manager gives only the name of an add-on, an icon, a version number, and a one-sentence description. Users could benefit from more information, such as a description or a screenshot showing what UI the add-on will change. Added functionality is also needed because of new ways to modify Firefox, such as Jetpacks and Personas. These are similar to current add-ons in that users can choose items to download for added functionality, but they are installed, managed, and used differently. A redesigned add-ons manager must be able to incorporate emerging projects like these.

Redesign Priorities

From fixing current usability problems to adding needed functionality, there’s a lot that needs to be tackled in the add-ons manager redesign. To help focus the effort, the main areas to address can be described as five priorities:

1. Maintaining and Configuring

  • Allowing users to quickly locate a particular add-on by name or by type
  • Providing simple, usable controls for basic add-on operations
  • Allowing new forms of add-ons, such as Jetpacks and Personas, to be maintained and configured easily alongside traditional add-ons

2. Updating

  • Updating add-ons automatically by default. I’m increasingly convinced that most users, once they’ve decided an add-on is trusted, do not want to manually update it. They especially do not want to be reminded to update when they are starting the browser
  • Allowing users the option to update add-ons manually, update only a particular add-on manually, and possibly to undo an update

3. Installing

  • Streamlining the install process to as few steps as possible
  • Providing the user with clear indications of what action is needed, especially when some add-ons require a restart and some do not

4. Discovering

  • Providing a compelling first-run experience to new add-ons users, including clearly showing what functionality add-ons provide and what they will change
  • Providing a usable, findable way on the add-ons manager to search all existing add-ons, only requiring a visit to AMO when greater community involvement or information is sought

5. Troubleshooting

  • Providing ways to determine if a particular add-on may be causing performance problems, such as ranking by size, CPU, etc
  • Giving clear communication and instructions if there is a security problem with an add-on

This is still very much a working list open to feedback and changes (especially via comments here or on the wiki).  Basically, what I’d like to focus on is making add-on usage less disruptive and more accessible. Experienced and especially technical users tend to be very aware of add-ons and the functionality they provide. These users may see add-ons mentioned in the tech press, may talk to their friends about their favorite add-ons, and might even get involved in the add-on developer community. These are the users who say “I can’t imagine a world without add-on X.” But the benefit of add-ons is felt almost soley by this group. There are thousands of add-ons available that can improve the online experience of just about any user.  Both users and developers deserve an add-ons manager that helps make customizing the browsing experience simple.

How could Microsoft’s Proposed Browser Ballot be More Effective?

By On November 2, 2009 In Firefox, Microsoft, Uncategorized, User Experience With 45 Comments Permanent Link to How could Microsoft’s Proposed Browser Ballot be More Effective?Permalink

(Note: This is my personal opinion and doesn’t reflect Mozilla’s official position nor any formal statement from Mozilla)

In my post on October 15, I wrote about the European Commission (EC)’s investigation of Microsoft due to its bundling of Internet Explorer (IE) with Windows, which the EC viewed as potentially harming consumer choice and innovation on the web. Microsoft, to appease the EC, proposed that Windows users be presented with a ballot in which they could choose which browser to install. I said at the time, and in a subsequent post, that creating a ballot would not successfully address the EC’s concerns nor provide a good experience to users. However, since the EC seems to be giving Microsoft the go-ahead to design a ballot, it seems that the best we can do is consider how to design a ballot that causes the least amount of harm to users.

Here are two broad principles that are important in ballot design.

Principle 1: A ballot should be clear and simple

A ballot should present the voter with the information they need to make an informed choice, but no more. The verbal and graphic language on the ballot should be organized so that readers follow a consistent path through the ballot’s information.  Many viewing the browser ballot will not be familiar with the browser as a separable element from the operating system, so clear and precise language is vital.

In interaction design, the complexity of a new task can be lessened by leveraging against what the user already knows and expects. For instance, it’s usually best to display the instructions in the top left for western readers, and before the the possible ballot choices (Kimball and Kropf 2002). It is also recommended that the instructions be as close to the first task as possible, because it provides the highest chance that voters will read them (Dillman and Christian 2002 (pdf)).

Other recommendations to make a ballot simple and clear include:

  • Instructions written short and simply, and in an active, affirmative style (Sanders and McCormick 1993)
  • No unnecessary information or clutter around the choices (Niemi and Herrnson 2003)
  • No text smaller than 12pt (Roth 1994), left justification preferred (Dillman 1978), shading and highlighting used to direct the voter’s focus (Kimball and Kropf 2002)
  • Ballot items listed in a single row or column (Darcy and Schneider, 1989). Failure to do this is part of what caused the ballot problems in Florida during the 2004 US Presidential election
  • Enough spacing between lines to highlight groupings of visual elements (Dillman 2000)
  • No ambiguity over which button corresponds to which choice (Kimball and Kropf 2002)

Principle 2: A ballot should be impartial

I wrote in my previous post about how ballot order can influence voters. Another important factor is how much physical space on the ballot each item is designated.

The current design runs into some problems with designated space per item, swayed in favor of IE. For instance, in the current design:

  • The user must double-click on an Internet Explorer icon, labeled “Internet Explorer”, to launch the ballot
  • The ballot appears within Internet Explorer browser chrome
  • Internet Explorer is mentioned repeatedly within the ballot, Bing is shown as the default search engine, and the IE logo appears as a favicon multiple times

The current space allocation for IE is roughly 3.35 times as much as the other browsers.

ie_ballotshaded

Current ballot: 3.35 times more space given to IE than the other browsers

piechart_browserballot

Allocation of visual space for each ballot choice

This space that IE occupies in the top left of the ballot is particularly important because it’s where users begin an eye scan of a new page.  As an anonymous source pointed out to me, Microsoft mentions this in their layout guidelines:

“All things being equal, users first look in the upper left corner of a window, scan across the page, and end their scan in the lower right corner.  They tend to ignore the lower left corner.

But in interactive UI, not all things are equal so different UI elements receive different levels of attention. Users tend to look at interactive controls—especially controls in the upper left and center of the window—and prominent text first”

Improving the ballot based on these principles

In summary, the ballot would be improved by being simpler, clearer, and be presented with equal weight to each browser.

Here’s a version similar to the current proposal but with these principles in mind:

top_buttons

Animation in Firefox: Area 1 of 3: Movement of toolbar items within rows

By On August 24, 2009 In Features, Firefox, User Experience With Comments Off on Animation in Firefox: Area 1 of 3: Movement of toolbar items within rows Permanent Link to Animation in Firefox: Area 1 of 3: Movement of toolbar items within rowsPermalink

For the next three posts, I’m going to be highlighting three areas of the Firefox user interface that could benefit from animation. Stephen Horlander and myself have been looking at Firefox with an eye towards where movement could make Firefox an easier, more appealing, and perhaps even faster experience with movement.

First, it should be asked why we would add animation Firefox. Animation in the browser is a tool, but not a goal unto itself. Wherever animation is used, it should be with a purpose (not “it looks cool”) and benefit to the user (not “makes user look cool.”)

afi011

Like many web technologies, animation is a useful but easily abused tool. The early web and the dawn of the .gif saw animation heinously overused with blinking, spinning, and scrolling animations added to sites because they looked cool.

As the web calmed down a bit and web and interactive design began to develop, designers and developers found that animation could be beneficial to users. For instance, it can make tasks seem more like real-world affordances, and thus easier to visually understand. It could give users feedback on how digital objects were being moved or manipulated. And yes, they could make interactive experiences more visually appealing.

The first area we feel could benefit from animation is the movement of toolbar items within their rows on the Firefox chrome. This includes buttons like Home and Reload, the bookmark bar, and tabs. Currently, these items can all be shifted and reordered, but little visual feedback is given for these tasks. For tabs, only a thin strip shows where a dragged tab will be dropped.

current_tabdrop

By adding animation to the process of rearranging items, not only will Firefox feel more lightweight and adaptable, but it will be more visually clear what the user is manipulating and how the UI will be changed by letting go. For instance, animations of tabs being manipulated is essentially live preview of tab rearrangement: if a tab is slid to the right and an animation shows it doing so, releasing it only makes permanent what is being shown. This is similar to the tab animation motion currently in Safari and Chrome.

tab_rearranging_animation

Because tab tearoff and tab rearrangement would utilize similar mouse movement, some thresholds should be added to prevent users from accidentally performing an unintended action. As Shorlander recommended, a “soft snap” could make tabs within a region of the tab bar slide, and falling outside that region causes them to tear off.

Slight animation could also give newly created tabs the feeling of organic growth into the browser.

new_tab_animation

(more details in the wiki)

The above sketches are based on work by Stephen Horlander.

Different use cases for live video want different display options

By On August 7, 2009 In Firefox, HTML 5, User Experience, Video Tag With 5 Comments Permanent Link to Different use cases for live video want different display optionsPermalink

In my last blog post about live video controls, I post some sketches of a prototype which could store some live video in a buffer for playback.  Thanks to everyone for the feedback, which was all useful.  I did want to draw attention to one point that James Heaver touched on: different uses of live video benefit from different ways of displaying the current time.  James uses the example of watching a live football game, where knowing what quarter the game is in is more useful than knowing the actual time.  In other cases, knowing the actual time (“4:30pm”) rather than the relative time (“you’ve watched for 4 minutes”) is more useful.  Here’s some examples of uses for live video that could require different time displays:

live_video_options_2

As we develop the video controls, allowing developers the flexibility to decide which display time and/or labels suite their content will be important.  Some video players today allow for toggling between relative and absolute time by clicking the timestamp: certainly an easy way to allow for both, if not very discoverable.  We may find there’s other ways to improve usability for high traffic events, such as sports games or shuttle launches, by storing buffered video remotely rather than having users buffer it individually.  Gerv points out that dynamically degrading video over time can allow for more content to be buffered, and Faaborg notes that there are instances that the user may want to save as much video as possible: two excellent points, which stress that making the video tag open and adaptable for the many kinds of content it can display is a primary objective.

Video controls for live feeds: instant replay for the web

By On July 27, 2009 In Firefox, User Experience, Video Tag With Comments Off on Video controls for live feeds: instant replay for the web Permanent Link to Video controls for live feeds: instant replay for the webPermalink

Watching live video online is generally a great experience. It’s a way to watch important world events without a TV, a way to view with friends without syncing, and still the best way to see a shuttle launch naked.

But online live video could be improved. For instance, there’s usually no way to rewind video to see a clip again, nor a way to pause and watch video from where you left off.  In fact, current implementations of live video have very few features – usually they are adaptations of regular video controls, but with non-interactive elements such as stationary or removed timelines.

2_other_live_player_examples

We think users would benefit from the ability to pause and go back in live video by keeping some amount of the video buffered.  However, this presents a few design challenges:

  • How to visually represent when the user is “live” vs. viewing buffered video
  • How to visually represent the amount of video in the buffer
  • How to make it easy for the user to jump between live and buffered video

Limi and myself did some brainstorming to develop ways to present this functionality. Below is an idea we had that we’d love feedback on. It’s based on the idea of a “live mode,” which users can enter and exit via the video controls. By default, the user begins in live mode (the box on the right of the timeline). As the user watches the live video, the timeline to the left encompasses how much video has been buffered. So, after one minute the timeline represents one minute in length, and after two minutes it represents two minutes. To give an indication of how much time the bar represents, ticks marking minutes will scroll left as the video plays. Clicking the live mode button or moving the slider back to the live point puts the user back in live mode.

3_live_mode_player

However, eventually the video will reach the maximum that can be buffered. For the purposes of these mockups, we’ll say that 10 minutes is the limit. After the video plays for 10 minutes, the beginning of the video is dropped and no longer accessible. The user sees this as the 0:00 mark disappearing from the timeline, and higher time markers continuing to scroll left.

4_live_mode_player_with_buffer2

If the user pauses the video, he exits live mode and the slider moves off of the live mode box. A visual indication will show that the video is no longer live – perhaps by fading the live mode and/or changing the shape and color of the slider. As the video is paused, new live video will be buffered and old video will continue to be dropped, moving the paused slider and the timeline left.

5_slider_moving_backwards

Once the slider has moved back 10 minutes, the new video is no longer buffered: only the ten minutes immediately after the pause is stored. This is so that when the user returns, the video will play from the point they left off and not the somewhat arbitrary 10 minutes before the live video. At this point, the buffered 10 minutes and the live point are no longer connected – a visual indication such as a break of the timeline will indicate this.

7_slider_break

So, what do you think?  Was this difficult to understand?  It’s a bit of a shift from commonly understood video control interaction, but I think it may be intuitive once users play with it.  I’ll be eager to find out.

You can read more about our progress in the wiki.

P.S. This is the first blog post I’ve made in awhile, but unfortunately for you I’m going to be posting a lot more frequently, starting now.  Please don’t cry, they won’t all be this long.

Improving everyone’s favorite feature – address not found

By On March 10, 2009 In Features, Firefox, User Experience With Comments Off on Improving everyone’s favorite feature – address not found Permanent Link to Improving everyone’s favorite feature – address not foundPermalink

One area of Firefox that could use some improvement are the warnings we give when pages are not found.  These could be network errors, firewall issues, URL typos, etc.  Curtis Bartley has been looking at this issue and documenting progress here, and Jesse Ruderman started a bug with some insightful comments here.

Ideally, a good error page does two things:

  1. Tells you what’s wrong in a way that’s both understandable and diagnosable
  2. Helps you decide what to do next

If I type “www.example.cmm” into Firefox now, here’s what I get:

current_network_error

Internet Explorer, Chrome, and Safari all have slight variations on this page.  IE’s isn’t very useful; it gives easy text but no tools. Safari’s design is very minimal, but it does offer search.  Chrome is cutesy, but also intelligently offers suggestions based on what was typed – the most useful of all three.  All three browsers offer additional information via a link, thus removing the bulk of explanation Firefox currently shows.

big_three_browsers1

So what should Firefox do?

For blatant, common URL typos, I think we should redirect straight to the correct URL. Google.com currently goes to http://www.google.com, why shouldn’t google..com or ww.google.com? URLs themselves are an example of forcing users to behave like machines – rather than the preferable reverse – so why not take a step in the right direction by making them more forgiving? (bug freakin’ 175634)

For the addresses that are not blatant typos for existing pages, there’s a few approaches we could take. User-experience-wise, I would love to be able to do better detection of what the problem is and direct the user towards the likely solution. Rather than presenting the user with questions as we do now, we could give them an answer.  We should aim to provide a consistent UI, but perhaps we could change the text sightly based on what the user inputted and try to find the most helpful suggestion. When there’s a very likely solution, that should be the most obvious next step available.

Here’s four scenarios that would cause a 404 today with text customized to what what the user imputed:

four_suggestions

While catching all of these scenarios may not be feasible for now, we could be concentrating harder on giving users tools at a 404, not just a warning. I’d love to hear you feedback on this – especially what would help a tech-saavy person such as yourself when you hit a 404.

Just for fun… spoilers!

UI Redundancies

By On February 18, 2009 In Chrome, Firefox, User Experience With Comments Off on UI Redundancies Permanent Link to UI RedundanciesPermalink

Firefox has a great user interface. It’s come a long way and a lot of very talented designers have worked to bring it to a place of visual and interaction stability. So, the question of how to improve becomes more difficult, but also more interesting.

This is an observation more than a criticism, but have you ever noticed how many redundancies occur in Firefox? Chrome’s tack has been to eliminate some of these and scrap the interface down to the bare minimum, which is probably going too far, but perhaps there are ways to clean the UI in places without sacrificing functionality or usability.indicators2

← Older Entries
Newer Entries →