I have made life difficult for the HTML / CSS developers by making any interaction that has a side effect into a button and NOT a hyperlink.
For example I changed the "Clear Basket" in a shopping site from a link to a button.
On the premise that any action that has a side effect should be a button not a hyperlink. (even tho a spider or robot will never get to this point)
How does this relate to REST?
The best answer will have good reasons I can use as to why I make things difficult for the HTML/CSS guys,... or why I'm wrong :-) ,... perhaps I'm being purist but for no real reason?
Note: I'm not averse to putting ajax functionality that has statefull side-effects on a hyperlink or even on selection-changed event.
Cheers.
Murray.
I think you did the right thing but justifying it is probably outside the domain of "REST".
If these links are truly just <a> tags that result in the browser making a GET request then clicked, then they shouldn't have any side effects because GET is supposed to be, per the HTTP spec, safe and idempotent. See earlier comments about spiders following the links, etc.
Now if the "links" used javascript to really do a POST to the server when clicked, or some kind of trick like that, then they are A-OK from HTTP's point of view. Probably more work than they're worth, but RESTful.
But there is user interface design to consider too. Because in basic HTML without CSS and javascript a link is always a GET, users have been trained since 1994 to expect anything that looks like a hyperlink to be safe and idempotent. By doing something different, your designers are in violation the principle of least surprise. This seems like something Jacob Nielsen would back you up on.
This doesn't really have much to do with REST, but I try to follow this simple rule:
Hyperlinks are for navigation.
Buttons are for interaction.
It does not really matter if your "stateful" actions are links or buttons. You can have a link that deletes/adds, etc. Consistency is what matters. So if you want to have these actions be buttons, that is fine. I think that talented CSS people can make links look like buttons. You may not need html buttons at all.
Related
I'm working on improving accessibility for a website, and I'd like to force JAWS to read a block of text in order to help the user.
For example, I have a help icon link that pops up a help modal. This modal contains some helpful text. I want to be sure that this text is read to the user. I'd like to have a solution similar to a div where I can do something like:
<div class="ForceReadText">
<p>Block of text to be read, that currently isn't being read.</p>
</div>
I'm not very familiar with JAWS, and my google-fu skills are failing me. I figured it'd be better to ask someone who might know how to accomplish this. Any ideas?
Forcing things is difficult and gives the appearance of rudeness. What I've done in the past for accessible modals is to make the icon that opens them a link, with the link pointing to the id attribute of the modal or its heading. If someone wants help, the click the link and are taken to the information (and will use the arrow keys to read the text); if not, they can just move on.
<img src="icon.png" alt="More information">
For what you are describing, it sounds like you might want an ARIA live region. MDN has an overview that may be of use.
For a quick overview, a live region is great fit for real-time updates to a page, such as errors or alerts. A live region has the ability to interrupt whatever a screen reader is speaking in order to speak the message instead. A live region does not change the location of the focus on a page.
The trick will be understanding that a page really should have just one live region.
The other trick will be getting all your messages into one live region, though it is certainly do-able if your pop-up behaves like a tool-tip (just re-use it).
If it behaves like a modal, keep reading...
Now, all that being said, the previous answer (from #stringy) is probably a smarter approach as long as you have good focus management practices (necessary for a modeal). If you do not, then a live region may be a better fit (and maybe less jarring).
Either way, take a look at these patterns and see if one addresses your goal:
2.3 Alert
2.4 Alert and Message Dialogs
2.9 Dialog (Modal)
Is there a standard way to code HTML buttons? One way I've been doing some buttons for a long time is to turn links into block-style buttons. I found though, that when I need a submit button and a link-button to look the same, it is very difficult to style.
Also, if I want to follow a more RESTful design, I'll need to pass HTTP DELETE and things like that as well.
Is there a standard way to code all of these buttons and be able to style them all exactly the same way?
No, there isn't a standard way.
However, if you need a button, just use a button. I think you'll also find it easier to style.
I'm working on a simple one-page calculator, heavy with JavaScript and form elements. Here is a static snapshot of the page as an example: http://pastehtml.com/view/1ce4ppo.html
Obviously it's very plain and I haven't put much emphasis on the layout of it yet. But this prototype is about to be shown to the client in a few hours. There is the understanding that it is a mockup prototype, so the client is not expecting anything design-wise, but I wouldn't mind if it looked a bit nicer.
What are some quick and easy tweaks I can make so that the page looks a little better? I'm terrible with colors and design but I know CSS quite well (like an English major who knows correct spelling and grammar but is terrible at writing a story).
Also, I am using jQuery in the form, so anything involving jQuery is great.
I would suggest the Blueprint CSS template You can use just the form CSS, seen here. All you have to do is add some classes to the HTML and you've got some decent forms.
give this a quick read: http://www.emblematiq.com/lab/niceforms/
i dont know if the javascript load is worth it for what you are looking for
I really like narrative style forms, where form elements are integrated in sentences which guide the user through the form-filling. Might not be for everybody(every form) but I think it's a really nice way of making your forms user friendly and stand out from the rest. Here you can find an example: http://www.lukew.com/ff/entry.asp?1007
When it comes to styling select, radio or checkbox inputs I prefer http://pixelmatrixdesign.com/uniform/.
I'd use one of the free template sites out there. I use them all the time, especially for a mock-up since I'm also not a design person. And in a lot of cases the customer enjoys the look or doesn't care. Just check what the requirements are for using the template, if there are any.
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.
I've been given the task of doing some work customizing an artist's space in MySpace. It seems that you sort of hack the HTML you want into your edit profile page (which has several empty boxes). The MySpace page, it seems, is already HTML so you can only hack into that. Suggested "tweaks" include incomplete HTML code (e.g., a <DIV> tag without a </DIV> tag to supress certain sections) and stylesheet pieces that you can "place anywhere" (meaning somewhere on your edit profile page). And the best one is that sites that offer layouts say, "Layout Code - Copy and Paste the code at the bottom of your 'I'd Like to Meet' Section!"
This cannot possibly be this lame, can it?
Is there any coherent guide to customizing MySpace pages for programmers/HTML designers? Is there a coherent DOM (including things like .contactTable etc.)? Could it be that all the tweaks are just hacks people have figured out from looking at the generated HTML?
Thanks!
This shouldn't be too hard if you whip out Firebug and do a bunch of "Inspect > click on page > edit CSS in Firebug's editor" work to see what you can learn about the structure of the page. Then mock it up to roughly how you want it and note down which elements and which styles need work and figure out how to get that set up in the profile editor.
Try approaching this from the point of view of a challenge. On the upside, MySpace allows you access to the DOM so you can screw with all sorts of things. On the downside, their choice of HTML composition is somewhat arguable.
You hit the nail on the head with your final question. The MySpace DOM is a disgusting set of nearly-infinitely nested tables. Normally, people edit the page by finding those sites that let you "cut and paste" and use their generated CSS since they've already done the hard work for isolating the proper elements.
Good luck... unfortunately, you are really going to need it. =/
Your fears are correct. MySpace "customization" is a bunch of hacks. Good luck.
You can a lot of information in this link: http://spiff-myspace.blogspot.com/
I think the same of the others answers: customize MySpace page is a difficult and complex task.
Regards,