Where I work, we use a multitude of various services such as Confluence, JIRA, Bamboo, Mercurial, and various others, that all have a web interface that our engineers can access through the corporate intranet.
However, many in our staff aren't directly network wizzes and having these services spread out confuses them. What I want to do is to set up a central server from which they can branch out and find all other web interfaces that relate to their work.
The first thought i had was to create a light web page with frames, using a top bar where the user can quick-navigate to any of the services available - but this creates an additional problem where i can't email someone a direct link to a page within a service, because it will remove that frame (and confusion will arise again when they see there's no way to navigate by clicks).
Is there some best practice to put this all together? Some hints? ideas?
First, stay far far away from frames. They annoy users something fierce (partially because of that not-able-to-bookmark issue you just spoke of.)
You could create a small webpage that could load within a popup window, which contained dropdown-nav links to all of the various tools. If you had the resources, you could even make it so that users could customize this window - so that they can add bookmarks to the tools they use the most.
But that does bring up the question...I'm guessing your staff isn't savvy enough users to know how to use bookmarks? Or keep going to a central link-repository page? Whatever solution you're thinking of, get input from a sampling of your user base, and find out how they'd actually prefer to work. They're the ones who are going to be using the tools, after all. Keep them involved, solicit their input, do "hallway usability tests" or any tool you end up building might be as useful as a chocolate teapot.
Related
I know there are several tools available to find unused CSS on a static web page. But in most real world scenarios I encounter, a lot of the CSS is used after some or the other interaction on the page, maybe a new modal opening up or an options popup etc.
In such scenarios, what would you suggest? How do I keep a tab on my ever-growing render blocking CSS?
The only way I guess one could do that is by running regular unused-css-detector type tools in conjunction with Selenium - test known interactions and see whats left unused. But a big assumption here is that I'd need to know all interactions on my page which could use new CSS. Is there a way to achieve my goal without making this assumption?
In an ideal world, I'd be able to post-back all CSS used by a visitor's browser on my page to my server. Then I'd collect data over a month, aggregate, and get a pretty accurate idea about actual unused CSS.
Any good ideas?
I am the author of a tool that is aiming at doing what you are describing. Everywhere I worked, the CSS is this "append-only" thing that is too risky, too time-consuming to clean up. And even when you try, the ROI is so low that it not worth it.
So I am working on a tool that is very similar to what you are describing. The goal is to bring confidence on what can be removed, and to actually do it automatically by submitting pull requests.
A snippet of JavaScript is running in the browser and sends reports of what is being used to a server. Once enough data is accumulated to build some "confidence score", it can create Pull Request automatically to remove selectors that are actually not used.
It is still very early stage, but you are welcome to try it and give some feedback about it.
https://www.bleachcss.com/
I like them more and wonder why they are not more common. Explanations involving caching or SEO make sense to me, but I don't see them as directly driven by user experience considerations. In which way are traditional sites with page reloads better for the user?
Personally I think the best argument for normal page reloads from a user's perspective is that when you do that it's much harder to break many basic browser functions. In general the back/forward buttons work, bookmarking works, copying and pasting links works, history works, page titles work, getting an error page when a server call fails works, everything just works as expected. For free.
I have seen single page application implemented in a way that breaks one or more of the above more times than I can count.
It's naturally not a problem if you get it just right (and then it will in general be nicer to use), but not all sites do.
Just as an example here's a screenshot how a site that is a SPA and justifiedly so (they have a music player that you don't want to interrupt with page loads), broke a basic browser function in a way they might not even have thought of. I was trying to find a song I recently listened to but couldn't remember the exact title... but because of the SPAness the page titles weren't properly reflected in my browser history.
I'm thinking of using a tree view for page navigation in my web application, similar to Windows Explorer. There are a lot of things for administrators to configure in the application so I figured listing all links in a single page in tree form would keep things organized. Related page links are grouped in a "folder", and all folders will show closed initially.
Obviously, this page is for administrators only, so they'd be provided with some training. That being said, is this a good design from user's point of view? Do you see any usability or potential implementation issues?
The best answer involves empirical evidence. A yes or no answer could really vary based on the specific task and your intended audience. Try doing a simple 5 minute usability test with your users. Draw out your page layouts on paper and have a couple of users pretend to use the site (see Paper Protyping). Give them a few simple tasks to complete using your interface and observe what they do.
If they get confused or have trouble with the concept, then it's probably best to find another way to provide navigation.
It totally depends on how your users are using your site. If they're often jumping from one part of the site to a completely different, unrelated place in the site, a tree may be the best way to let them quickly find that "other page" they were looking for.
However, for the vast majority of websites I've ever seen or used, I'd prefer to find what I'm looking for either via Search functionality, or by links on the page I'm looking at that lead me to related data.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Designing a web application, how do you design the main page? By this I mean the page that is displayed to a user after entering the base url, like http://www.foo.com.
It would probably depend on a website, but...
stackoverflow welcomes us with list of questions, no silly what is stackoverflow landing page,
last.fm prestens a kind of dashboard, being very popular lately, kind of personalized landing page for registered users
google welcomes us with a search box, but iGoogle i completly diffrent story - looks diffrent for everyone (well, and that's the point actually).
The other thing is, if the user is logged in (provided the website supports logging in), should we present him a diffrent content there then some new, random incomer? And I don't mean some personalized content, but something completly diffrent, like his user profile instead of main page?
From one perspective it could be good - registered users usually know our site, and get a kind of special greeting as soon as they come back. On the other hand, this could cause problems - when I show a website to a friend, then he goes there from his computer and sees something totally diffrent.
And other thing is, when I show a http://www.foo.com to a friend, and it takes me directly to my user profile / dashboard - this isn't sometimes what I'd like to show everyone, as this might show some of my personal data, etc.
What do you do when you design your web applications? What's, in your opinion, best from user's point of view, do my concerns about the website looking diffrent for registered and unregistered users do or don't make any sense? (Again, I don't mean small diffrences, like hiding huge register now link - but showing completly diffrent view then).
It really depends on the focus of your application, but if you were to generalise I would say determine the one or two most critical paths in your application and focus on those.
Registration is probably what you
want to drive more than anything
else, so make it clear how users can
sign up and get involved.
Make it is easy for existing users to sign in.
Consider the amount of text you have
on your front page and reduce and
pair it down as much as possible. Keep the messages and information you
convey here as succinct as possible.
Provide some content immediately
showing what your application or site
provides. Don't make users follow a
link to access the core functionality
of your site immediately e.g. if
you're building an auction site,
ensure there are listings on the
front page.
Consider your audience. If your site is non-technical, the fewer UI elements you present the better. Portal like sites, with lots of compartmentalised functionality and information can be confusing and overwhelming for many non-technical users.
Make it clear how users can get Help if they require it
Without knowing the business area of your site then it's going to be tricky to answer this, but...
You should get the user into the main flow of your website as soon as possible, and the home page is the best place to do this.
If you're an online store, start showing your products.
If you're a search engine, give the user the ability to search.
If you're a blog/news site, show the user the latest news.
Yes - make the experience for a logged on/registered user better (show them THEIR news, show them their recommended products etc), but the purpose of your site should be obvious and accessible from that home page. Get your existing users into their flow as soon as possible, and attact new users in to your site by showing them the meat of your site.
There are plenty of places out there that discuss good web design, making your site "sticky" etc. Check out SmashingMagazine.com (it's one such site) but there are plenty of others.
Oh, and remember that there's one very important user of your home page that you need to accomodate - search engines. Make their life easy, make the content discoverable and indexable, and drive people to your site via Search.
What I've found works best for me is to "role-play" the end-user's experience.
When they initially hit your site, what do they most want to see, or in other words, what are they most likely to be looking for and wanting to do?
I work on many intranet websites for a very large company, and what I've learned is that a home page that has detailed information of the site and what it does is useless and, consequently, my end-users just skip over it in order to get to the pages that they really need. So, my strategy usually consists in a home page that allows them to get straight down to business and whatever they're there to do.
BUT, that's just for the sites that I create. I think it totally depends on your target market and what they're wanting to do.
For the most part, a visitor landing on your page will already know the gist of what your application is about, so there shouldn't be a need to explain in detail what is is you do. Instead, show them that you have the information they are looking for. Screenshots and screencasts are becoming popular these days as a means of getting this across to the short-attention-spanned user.
For registered users, I'd recommend taking them directly to the primary application page instead of the homepage (unless the homepage is the primary application page). For many apps this is a Dashboard (Flickr, Basecamp, Campaign Monitor). If your app's main focus is the homepage, you may want to show them a personalized version of that page (think Google vs. iGoogle).
With all this said, it really does depend on what you are building. Every application is different and there's no right way to do it - only conventions that work for most.
I would start by looking at the type of tasks that can be performed inside your web app, what's important? what's important when they are a new user? what's important when they are a repeat user? what's important when they haven't even registered yet.
Although all of these things happen on the the same page, it's likely that you'll need to define different states. e.g. If a user is on the homepage and not logged in, should we prompt them to login and register.
Perhaps also look at Personas so you can figure out exactly who will be using the app and what is relevant to them.
It should be whatever makes sense for the application, and this should be verified by testing the application with a group of expected users.
The main page should provide a first-time user with enough visual and/or written information to understand what the application is about. They should have some idea as to what actions they can take to interact with the app and what the outcomes of these actions could be.
I know people hate this answer on stackoverflow but there's only one way to find out what the most appropriate thing for your users is - you need to brainstorm ideas with potential users or at the very least you ask them.
I'm not suggesting that you do a focus group, or put a flawed poll up (neither of those things work). Rather, I'm suggesting that you go out and talk to people who will potentially be in your target users and do planning games with them (like card sorting) or go out and do some user testing with paper prototyping.
Anything else is guessing.
We are designing a web site and have run into some UI challenges that would be neatly solved with a tabbed interface. Users will interact with different elements of the site (there are some basic view/edit/copy/paste functions available) and having only one object in one tab visible at a time simplifies things quite a bit.
We are, of course, completely comfortable with tabbed interfaces but what about novice users? I've searched the web for guidance and I haven't found anything definitive. Do you have experience presenting a tabbed interface to novice users and did they have trouble with it? Or, have we reached the point where everyone is comfortable with tabs and we can use them without reservation?
Usability is important-- more so for this project than most. If naive users are confused by a tabbed interface it just won't work and we'll have to find another way.
In his excellent book "Don't Make Me Think" (Sensible.com), Steve Krug discusses the benefits of using a tabbed interface:
They're self evident
They're hard to miss
They're slick
They suggest a physical space
He goes on to describe the keys to successful tabs as demonstrated by Amazon.com:
They were drawn correctly
They were color coded
There was a tab selected when you enter the site.
Obviously, he provides details to each of these bullet items in the book (I won't plagerize him here). The book is definitely worth a look if you want guidelines for creating web sites for novices and experts alike.
Tabs are becoming common place enough that I wouldn't worry about using them, as long as you implement them correctly. Make sure that you make the active tab visually distinct from the other tabs.
Also, try to create the tabs using progressive enhancement so that the content is still there with JavaScript disabled. There are two main ways of doing this:
Load every tab but the first using
AJAX. The tabs themselves should be
links to the content that the AJAX
fetches.
Keep all of your information on the
page, but hide it using JavaScript.
When you cycle through the tabs,
they are populated from the hidden
parts of the page.
A design resource you might find helpful is the YUI Design Pattern Library and their section on tabs.
I think as long as the tabs are visible as such it's understandable by the user. I have seen websites where they present a vertical bar with links that act like tabs but it's not immediately visible to the user and found that very confusing.
I would have to disagree with those are in favor of tabs. In a design test we did for a fairly high-traffic website (over 1mil uniques at the time), we found that tabs have not been used. Tabs were clearly marked, located to the right of the main content area. Based on that experience I would suggest either finding an alternative or, as staticscan suggested run usability tests to figure out which ones work.
Don't think you can decide a-priori what is usable and what isn't. Do usability testing
"It takes only five users to uncover 80 percent of high-level usability problems" Jakob Nielsen
Google usability testing and start learning. It's not hard.
I tend to agree with lothar and ricebowl - people seem pretty familiar with it these days. The most important thing with any GUI element is clarity - the user must innately know what will happen when they press something (they know that clicking an inactive tab will make it active); and in navigation - it must be very clear exactly which tab they are currently on. As lothar said, if it's not immediately visible to the user, it's very confusing. If you address those issues, then it should be fine.
Just wanted to note SmashingMagazine has a new article showcasing tabs: Showcase of Tabs
I think people are used to the metaphor (from binders, or card-indexes and so forth) of tabs. Especially those that use the web for any length of time. I think that, if IE's adopted a metaphor, it implies a common familiarity with that metaphor.
So, no, I'd suggest that they're not confusing and suggest that you go for it. Just, maybe, post a welcome/first-time introduction (or a prominent 'help' link to such an intro) to the use of the tabs.
I've been a developer for an intranet app that used a tabbed interface, generated with HTML and controlled by JavaScript. This was way before IE7 and Firefox. In fact, it was a bit of a novelty on websites in general, too.
Fortunately, a previous developer had discovered that if you made it look like a dialog box - even down to using a grey background, then people usually understood the metaphor. We also loaded all the content for all the tabs in the initial page-load, and had the Save/Cancel buttons outside the tabbed structure. Because of this, most people immediately understood that they could move between tabs (we used JavaScript to hide and show the DIVs) and a Save would save changes to all of them.
If you want to deviate from such an obvious metaphor, then you need to do some usability studies.
A well implemented Tab interface should not confuse users.
In line with what others have said one of the most ipmortant things to consider with Tabs, or any other navigation interface is for it to be obvious where they currently are in the navigation scheme.
Another important point is not to break the browser! Many AJAX or javascript implemtations break the back button. This is a minor annoyance to some and a major inconvieniece to others. Make sure to consider your target audience here.
Personaly I prefer the oldschool method of not preloading all of the tabs but having each tab as its own page and using a templating methodology to manage the navigation interface, be it tabbled or otherwise. This maintains the browser history and works fine with or without javascipt.
Tabs, etc are just tools. How we decide to lay them out and use them is what determines their effectiveness.
What I try to keep in mind is:
1) Keep it close. The things we use the most should be on the front or up close to the top as much as possible and bury the rest based on how often they are used/adjusted.
2) Easy enough for Mom to use. All interfaces are confusing if they are not laid out in a clear and logical manner.
3) Organize how it's used, not how you think it makes sense.* I often use tabs to break up steps in a process, or to break up areas such as basic / advanced options. I group them based on similarity or usage depending on what works better
4) Keep them few Either way I try to stay below the 7-10 range tops as the human brain has a hard time jumping beyond 7-10 digits, so I assume the same for pieces of information. Vertical Accordians might be something you want to look into as well.
I have also embedded tabs within tabs before. Works well but only one layer deep most of the time.