×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

A Good Style Guide Under the Creative Commons?

ScuttleMonkey posted more than 6 years ago | from the build-something-that-doesn't-suck dept.

Software 131

eldavojohn writes "I've been charged with making a specific user interface style guide for a suite of software by my employer. I'm not quite sure where to start. So I turned to my favorite search engine only to be brutally disappointed with what is out there to help me. I'm a software developer but have not had any formal training in UI design or look and feel. I'm looking for something more than just "keep it simple, stupid." I'm looking more for something that is specific but not technologically dependent. This doesn't have to be a global standard, merely a document that illustrates how one would effectively describe look and feel. Does anyone know of such a guide either created by an organization, government or company for their own uses — possibly one even released under the creative common license?" In addition to just documentation, what other UI advice can Slashdot readers offer in order to ensure quality development?

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

131 comments

And what's so wrong with ... (1)

trolltalk.com (1108067) | more than 6 years ago | (#22604414)

I'm looking for something more than just "keep it simple, stupid!
Try 42. It doesn't get much simpler than that.

Re:And what's so wrong with ... (2, Insightful)

BigJClark (1226554) | more than 6 years ago | (#22605258)


I dunno, it took over 7million years and the second greatest computer of all time to come up with that answer.

Doesn't seem overly simple to me.

quack quack.

Apple Human Interface Guidelines (5, Informative)

Foofoobar (318279) | more than 6 years ago | (#22604466)

Macintosh develop site has several well put together style guides for software development that you should look at. Check out the Apple Human Interface Guidelines [apple.com]. Apple may not be your cup of tea but they always have good ideas and have a well put together interface and this will DEFINITELY give you a good idea where and how to start.

Re:Apple Human Interface Guidelines (5, Informative)

JustinOpinion (1246824) | more than 6 years ago | (#22604980)

Since the original poster seems to prefer permissive licensing, he should also check out the GNOME Human Interface Guidelines 2.0 [gnome.org]. It's an extensive set of best-practices and guidelines, licensed under the GFDL. Thus he can tailor the guidelines to his needs and redistribute them without worrying about copyright issues (another poster suggested setting-up a wiki for his users, which could also work).

The KDE Usability Guide [openusability.org] also has some good material, although at this time it looks much less mature than the GNOME docs.

Re:Apple Human Interface Guidelines (5, Informative)

try_anything (880404) | more than 6 years ago | (#22607058)

OSX, GNOME, and KDE are all very usable environments, but style guides mostly tell you how to achieve consistency with other applications on the platform. If the OP is really asking for a style guide of this kind, he needs to tell us what platform he is developing on. Using an Apple style guide to create a Windows program will result in a less usable design, even if the Apple guidelines are superior to the Windows ones.

For an introduction to UI design, here are some good resources:

Re:Apple Human Interface Guidelines (1)

try_anything (880404) | more than 6 years ago | (#22607274)

Addendum to explain my reasoning, in case it wasn't clear why I was dismissing the question as stated. The interest in permissive licensing is fishy. If he indends to quote significant chunks of a style guide for the wrong platform, then it's a very bad idea. Plus, there's ALREADY a style guide for his platform -- if he's working for any major desktop platform -- and it would be redundant to quote it. He can just tell his coworkers to go read the damn thing, and he can provide a project-specific appendix (which would be modeled after the standard style guide for his platform, to ensure consistency in terminology and style.)

So, what has he actually been tasked to create? He says he doesn't want it to be "technologically dependent" which makes it sound like he has been tasked with educating beginning UI programmers on general UI design principles. That's consistent with his company putting a guy with no training in UI design (which also means not much experience, or he wouldn't have mentioned it) in charge of the effort.

Apple (1)

TheRaven64 (641858) | more than 6 years ago | (#22604474)

Read the Apple Human Interface Guidelines, ideally a version from before OS X when they weren't trying to merger MacOS and OPENSTEP HCI principles into a coherent framework. They're well written, contain rationales for most of their descriptions and full of examples.

Re:Apple (1)

bigstrat2003 (1058574) | more than 6 years ago | (#22605670)

ideally a version from before OS X
O.o

Say what? I don't like OS X, but it's a vast step up from prior versions. Before X, Mac OS was a clusterfuck of bad usability. Now, it's at least passable. Why would you follow any version before OS X? Serious question.

Re:Apple (1)

vijayiyer (728590) | more than 6 years ago | (#22606822)

I'd take OS X over a previous version any day, but strictly in terms of user interface, previous Mac OSs were better. The finder actually was a graphical representation of the the disk - you didn't have multiple windows with the same files appearing in it, for example. It always remembered where you placed icons, your view settings, etc. OS X violates many of Apple's own interface guidelines leading to the mess that is the current Finder. Things like file sharing were trivial to set up with simple fine-grained controls over each directory (which finally reappeared in Leopard). All that said, I'd gladly take the UNIX underpinnings and shell of OS X over OS 9.

Not really sure what you're looking for, but... (5, Informative)

ruyon (660897) | more than 6 years ago | (#22604480)

How about taking a look at these well-known samples?

GNOME HIG

http://library.gnome.org/devel/hig-book/stable/

Apple's HIG

http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGIntro/chapter_1_section_1.html

Re:Not really sure what you're looking for, but... (4, Interesting)

Anonymous Coward | more than 6 years ago | (#22604774)

Not that anyone will ever even see this since the new Slashdot comment system doesn't even show anonymous comments, but...

The GNOME HIG is, in fact, licensed under the GFDL, which effectively meets the Creative Commons request. It's definitely a good place to start.

But when using those, remember they're tied to the individual desktop. Things that are standard under GNOME and Apple are reversed under Windows. (For example, Windows always uses "Yes/No/Cancel" while both GNOME and Apple recommend using action verbs. Plus Windows generally places the most used option in the hardest to hit location while GNOME and Apple place it in the easiest to hit.)

The important part here is that the software should follow the guidelines for the platform it's running on. Not following them will just annoy people using that platform.

I'm also not sure that's what he's looking for. Those are guidelines for an entire OS and not a software suite. In a software suite, you'd want to make sure that certain workflows are always handled in a similar manner. You also want to make sure icons follow a single art style. For example, a common palette and a common set of icon elements. (Like the envelope in email clients which are often used in the Compose/Reply/Reply All/Forward buttons.) These things are somewhat covered in an OS HIG, but are sort of outside the scope.

Sadly it appears that very few open source projects actually create such documents.

And now I send this post to disappear, because apparently anonymous posts aren't worth mentioning, even with a "hidden posts" link.

Re:Not really sure what you're looking for, but... (1)

laughing rabbit (216615) | more than 6 years ago | (#22605414)

I saw your anonymous comment.

WTF are you talking about?

I don't agree with your statements. Gnome is not an OS, it is more of a GUI shell for the OS that has interoperable programs that pull look and feel from the shell. Like a lot of software does on a lot of differing platforms. The thoughts outlined in the HIG can be translated by any intelligent person to fit their needs. The poster just needed an idea of how to proceed, and the HIG does an excellent job of providing a jump point.

Re:Not really sure what you're looking for, but... (0)

Anonymous Coward | more than 6 years ago | (#22605440)

Oh, it shows anonymous comments. Just not yours.

Re:Not really sure what you're looking for, but... (0, Flamebait)

trolltalk.com (1108067) | more than 6 years ago | (#22604786)

How about taking a look at these well-known samples?

GNOME HIG

The Gnome interface Guidelines? You've GOT to be joking! The guidelines that say to do stuff the opposite of everyone else "just 'cuz!"

More like "what NOT to do."

Re:Not really sure what you're looking for, but... (2, Insightful)

Chandon Seldon (43083) | more than 6 years ago | (#22604976)

Gnome is consistent and very usable - so their guidelines seem to be working. I'm not sure what your complaint is.

Re:Not really sure what you're looking for, but... (2, Informative)

trolltalk.com (1108067) | more than 6 years ago | (#22605310)

Gnome is consistent and very usable

Only with itself ... the order of buttons on dialog boxes is f*cked up. For example, in the GIMP : Create a New Image, the order is [Help] [Reset] [Cancel] [Okay]. Last I looked, this was an LTR (left-to-right) locale. The default action in EVERY other environment is on the left in LTR locales.

Their rationale for doing it different was 90% ego bloat, 90% stupid (with an 80% overlap).

Re:Not really sure what you're looking for, but... (0)

Anonymous Coward | more than 6 years ago | (#22605380)

I suppose I should know better for responding to someone named trolltalk.com, but...

The GNOME order is the right one. It's the same that Apple uses. It places the most frequently used button on the right, where it's easiest to hit.

Windows, by contrast, places the most frequently used button in some random location because it floats with the length of the button labels.

In GNOME, to accept the most common, you always hit the same location. It takes advantage of muscle memory. In Windows, you have to carefully read through the options and figure out where the button has migrated to in this specific dialog.

It has nothing to do with read order, and everything to do with which button is the easiest to hit.

Re:Not really sure what you're looking for, but... (2, Interesting)

trolltalk.com (1108067) | more than 6 years ago | (#22605542)

In GNOME, to accept the most common, you always hit the same location.

No you don't - the rightmost button is the 2nd, or 3rd, or 4th, or whatever - it varies with the number of buttons.

Putting the default as FIRST would mean always hitting the same location.

The right-hand side is the wrong one in LTR locales.

It isn't "the easiest to hit" unless the window/dialog/whatever is always a fixed size. Otherwise, its position is floating, and it is the last in a series of "N" buttons, instead of the first, requiring you to scan all the previous buttons.

In contrast, the left-most button, as the first, is the first to be seen in LTR locales, the first to be read, and if its what you're looking for (as the default action) you need go no further.

Before GUIs, the default action in most apps was almost always the leftmost. All Windows did was copy that. It makes sense.

Re:Not really sure what you're looking for, but... (0)

Anonymous Coward | more than 6 years ago | (#22606294)

Location, as in "position relative to the window which has called your attention".

Not as in "position on a hypothetical array of buttons in your head" on which you do a while-loop to select some i-th button with i ranging from 1 to n.

The idea is that developers should (in GNOME, at least) put the 'recommended' or 'most used' option in the bottom right corner, where it is easy to hit and see.

You see rectangle on screen which says some stuff and tells you to do choose an option to do (or not do) stuff. You see the option shown in the bottom right corner. If satisfactory, you click the button that presents it. If not, you don't and see the other options. If it really is the most often used option, then you save time by just looking at the one in the corner first and clicking it.

If they put it first from left to right, you would have to look for it in one of the many locations it could be, instead of just looking in the right corner of the dialog, which is a fixed location within it (ther can only be one, duh!). Unless of course the buttons were left-aligned, but that isn't the case in neither Windows nor GNOME.

Posting AC because I have moderated, I'm not the previous AC.

Re:Not really sure what you're looking for, but... (0)

Anonymous Coward | more than 6 years ago | (#22607168)

It isn't "the easiest to hit" unless the window/dialog/whatever is always a fixed size. Otherwise, its position is floating, and it is the last in a series of "N" buttons, instead of the first, requiring you to scan all the previous buttons.
Nice discussion (including parent's predecessors). Well, what disturbs me most in this "easiest to hit" discourse is the way the user is supposed to hit something. I use the keyboard to hit things--in Gnome, I find it very difficult to navigate to different folders using F6, followed by entering the (auto-completed) path. Don't they have a proper location bar in Gnome?

Re:Not really sure what you're looking for, but... (5, Informative)

Chandon Seldon (43083) | more than 6 years ago | (#22606520)

For example, in the GIMP : Create a New Image, the order is [Help] [Reset] [Cancel] [Okay]. Last I looked, this was an LTR (left-to-right) locale. The default action in EVERY other environment is on the left in LTR locales.

Except Windows, where the default action is in the middle (i.e. the hardest to find possible choice):
Windows Dialog [georgetowncollege.edu]

Or Mac OS Classic, where it works just like in Gnome:
Mac Classic Dialog [georgetowncollege.edu]

Or In Mac OS X, where it works just like in Gnome:
OS X Dialog [primarysou...arning.org]

I can't find a screenshot, but KDE seems to work like Windows.

I still don't see what the problem is here. There are two common ways of doing it. Mac and Gnome do it one way, Windows and KDE do it the other. *shrug*

Re:Not really sure what you're looking for, but... (1)

ajs (35943) | more than 6 years ago | (#22604840)

Yes, the Gnome HIG is really quite nice. Props to Sun for all their work on it!

Re:Not really sure what you're looking for, but... (2, Insightful)

Ox0065 (1085977) | more than 6 years ago | (#22606720)

My only comment would be that:

The introduction of the Gnome HIG brought about substantial stripping of functionality out of gnome.
It's heavily tailored toward lowest common denominator computing. It does make flexible & robust GUIs.
They just don't do anything you want.

... (^-^)

Practical first step (1)

ingo23 (848315) | more than 6 years ago | (#22604500)

I'm not quite sure where to start.
Start by hiring a consultant

Re:Practical first step (2, Funny)

Intron (870560) | more than 6 years ago | (#22604536)

Then form a review committee and start issuing minutes.

Re:Practical first step (0)

Anonymous Coward | more than 6 years ago | (#22605894)

... and then follow only part of the recomendations; just the ones that suit you, or that are simple to implement. When bugs are written, say "its only a guildline!"

From India (0)

Anonymous Coward | more than 6 years ago | (#22604550)

Better yet, hire a consulting company from India. They'll help you out.

Re:From India (1)

(TK2)Dessimat0r (669581) | more than 6 years ago | (#22604746)

If by 'help' you mean reciting the Qur'an 1000 times and building mosques in our fucking country, you're quite right.

Re:From India (0)

Anonymous Coward | more than 6 years ago | (#22604892)

You're mixing up your cultures....

Best style guide? (0)

Anonymous Coward | more than 6 years ago | (#22604528)

The best style guide is made with lots of beer. After your first 20 or 30 beer, everything looks good, including the toothless old hag hanging out beside the dumpster.

Re:Best style guide? (0)

Anonymous Coward | more than 6 years ago | (#22607156)

What are you drinking, water?

Simple rules (0)

Anonymous Coward | more than 6 years ago | (#22604556)

Is this like an corporate identity / branding thing?

Give people simple guidelines, such as: Use these logos (provided in various sizes and image formats). Use this typeface for headings and this one for text. Use these few colors. And make sure that whatever objet d'art you create doesn't look like too much of a turd.

Alternatively, email a member of the GIMP team to ask for their UI guidelines... and whatever it says, do the opposite.

Re:Simple rules (2, Funny)

eln (21727) | more than 6 years ago | (#22604920)

And make sure that whatever objet d'art you create doesn't look like too much of a turd.
I really don't understand the need for this rule.

Signed,
Chester W. Lampworth
President and CEO
Amalgamated Manure, Inc.

Hire an artist. (1)

retech (1228598) | more than 6 years ago | (#22604588)

Different brains are wired for different things. A good programmer is rarely a good designer and vis versa. This was dictated at conception by how we are hard wired. There are somethings in life that will always be outside of each of our abilities. It's best to recognize this and hire someone who excels where you lack.

Re:Hire an artist. (0)

moderatorrater (1095745) | more than 6 years ago | (#22604758)

This is exactly right. I know of very few engineers who are also talented artists. When it comes to UI, you need both; the artist should come up with the general look and feel, and the programmer should add the functionality within that framework. Usability goes up at least 200% when the program is made to be good looking.

However, that's not to say that programmers are any less important. 200% of shit is still shit, and every UI requires some functionality behind it. Artists generally won't know how to wring maximum functionality from the application. The point is that you can't work without these two factors working together, so make sure you don't focus so much on one area that the other suffers.

Re:Hire an artist. (5, Insightful)

neurosis101 (692250) | more than 6 years ago | (#22604962)

I almost never post on /. but seeing this I can NOT pass up.

Creating a good interface is about FAR more than just pretty pictures. An artist might make it look good, but looking good and being functional are not related in any way, shape or form. I've seen art houses produce UIs that were illogical and violated many basic UI principles but look nice. The worst part is your client will fall in love with the looks without thinking about the damage that is being done.

If you are going to bring in outside sources, there are art houses that have specific UI design experience. You should make sure you engage one of these. Or come up with a design, then have the art house make it look nice.

Real UI design is about user cases, apprentice-master relationships, and other things 99.9% of artists don't know anything about.

Re:Hire an artist. (1)

What Is Dot (792062) | more than 6 years ago | (#22605846)

Just to be clear, there is a different between being a talented artist and a talented designer. I am a student who has took classes in interface design and I have noticed a recurring theme. We always want to separate content from design, if not physically then mentally. I find it helpful to sit down and make a list of all of the important features that a person would need access to at this 'state' in the interface, and when the user needs more detail, he proceeds down to the next 'state' in the interface. Grouping information by relevance should help reduce the odds of ending up with a window consisting of only one check box, or a window containing 100+ options for a user to have to swim through all at once. The design comes only after we know what content we need to display. HOW the content is organized on a page, and how it is accessed can reduce the user's time dramatically. In the end, the design should never dictate what content should be displayed. It's the complete opposite.

Re:Hire an artist. (1)

Hatta (162192) | more than 6 years ago | (#22605396)

Different brains are wired for different things.

And because of this, one size does not fit all when it comes to UI. Always, always, always separate your actual functionality from presentation, so that people can implement and use the UI that fits them best.

Personally, I find apps like Rasmol, Gnuplot, and R to have the finest UIs available. Which is to say they only use graphics when absolutely necessary and everything else is done through a command line. I just find the language metaphor a more compelling and powerful way to interact with my computer, rather than treating it like a physical object to be manipulated with the hands. But would you find any HCI expert anywhere who would recommend such a design?

Some suggestions (4, Informative)

RobBebop (947356) | more than 6 years ago | (#22604590)

Know the author Ed Tufte [edwardtufte.com].

Know what HCI [wikipedia.org] stands for.

Know your audience and let them evaluate Throwaway Prototypes [wikipedia.org].

If you are looking for a book to teach you UI design, you are misguided. If you are looking for a Creative Commons and/or Open approach to UI design, register a domain called "Principles of UI Design" and launch a Wiki on it, then license it with the license you desire (but I would recommend CC0).

If all goes well, this thread will serve as a good starting point for getting ideas/content to populate your new Wiki with.

Re:Some suggestions (1)

evilklown (1008863) | more than 6 years ago | (#22604886)

If you're not opposed to reading a bit, check out The Design of Everyday Things [amazon.com] by Don Norman. It's not specifically a guide to writing better user interfaces, but it definitely helps with making user interfaces more practical.

Re:Some suggestions (1)

Rhalin (791665) | more than 6 years ago | (#22605040)

Know the author Ed Tufte. Know what HCI stands for. Know your audience and let them evaluate Throwaway Prototypes.
Great starting points here. The audience one is a massive factor.

For instance, are your programs for designers, artists, programmers, office workers, etc? Different groups tend to use applications in different ways. They've also been exposed to different styles of UI design. An important factor is often not to "surprise" your audience with some neat new UI trick *cough* Office 2007 Ribbon *cough* because it tends to frustrate them if it is different then what they're used to in similar applications. However, there are times when this is acceptable - I'll admit, once you get used to it, the Ribbon is can be rather handy.

Your audience is also important in how they use the application in their workflow. If you don't know how they work with the app, you'll be shooting in the dark as to what it should look like and how useful it will be to them. I've been given several projects where I get specs and a general idea of what the app is used for, and I end up going straight to the people that -actually- use it and asking them what they need it to do. The end result is much better (for the users) then what they would have had if I had just gone straight from the specs. Throwaway prototypes are -very- useful for this, and continued development.

Your example runs into a bit of an added problem because its for a suite of tools, and not just a single app. That means you'll need to evalute each tool invididually, and it's audience, and try to come up with set of design standards that fits the majority - but don't throw out all the exceptions. Sometimes an app needs something thats a little different then something else in the suite, it happens.

There are some great papers written about how to do this using anthropological ethnographic field methods, but chances are you won't have the kind of time to delve into reading something that lengthy. The best bet is doing some googling for HCI and see what you come up with.

As others have mentioned, hire a consultant if all else fails. There are people that specialize in this. They know what to look for, who to talk to, and how to evaluate the needs of the users.

Re:Some suggestions (3, Insightful)

Simon80 (874052) | more than 6 years ago | (#22605486)

I think the ribbon has been unfairly criticised since it became public. It eliminates the redundancy of having both menus and toolbars with the same commands in them, and makes better use of the space on the screen.

To be clear, I'm generally a critic of Microsoft, since they can be trusted to act in their own interest no matter how much they try to make it seem otherwise, and I've never used Office 2007 before. Despite that, I disagree with the ribbon bashing bandwagon people seem to want to jump on - there's plenty of legitimate things to criticise about Microsoft, no need to latch onto something that is actually a good idea. Also, this isn't directed at the post I'm replying to specifically, it's more of a generic rant about ribbon bashing.

Good Interfaces (1)

solprovider (628033) | more than 6 years ago | (#22606388)

"Know the author Ed Tufte."
I like Tufte for his arguments against using PowerPoint. His own works are mostly about using images to display information well. While some important HCI topics are covered, finding the few critical points would be much work for someone with an immediate need to create a guide for interfaces.

"Know what HCI stands for."
Much good information can be found with much less work by reading the free materials from the organization that certifies HCI professionals:
      http://www.humanfactors.com/ [humanfactors.com]
The only other certification requires a Masters degree in the subject, at which point another certification is pointless.

"Know your audience and let them evaluate Throwaway Prototypes."
Your audience is human beings. Dividing any further is an excuse for allowing poor interface design.

"If all goes well, this thread will serve as a good starting point for getting ideas/content to populate your new Wiki with."

I have two rules for good UI on my website (which needs better organization and will be fixed later this year):
1. Make every function as obvious as possible.
2. Require the least action for every function.

Many interfaces hide functions with menus, tabs, and dialog boxes. The functions are hidden, and activation requires more than one click. Some programs even show functions that cannot be used. (Photoshop has so many options that hiding some is almost necessary, yet still shows actions that cannot be used at the moment.)

The third rule should be to minimize the probability of mistakes. Many environments have dialog boxes with "OK" and "Cancel" buttons very close. Buttons should be explicit. Damaging actions should be separated. All options should be allowed.

Firefox is better than most programs and still violates these rules. If you attempt to close a window with multiple tabs open, the buttons are "Close all tabs and this window" and "Cancel - Do not close any tabs" (italics added for missing text). No option is presented for the most likely desired option to "Close the current tab".

These three rules cover every situation. More guidelines are useful for consistency, such as
- The expected action is always first and has a green background.
- Other actions may follow with yellow backgrounds.
- Cancel and other destructive actions are always in the bottom-left at least 20 pixels from other controls and have a red background.

/. Home Page Direct Link To an MP3? (0)

Anonymous Coward | more than 6 years ago | (#22604606)

I guess thats one way of band promotion - get a front page story on /. with a direct link to your mp3. How're those servers doing again?

Quality development? (0)

Anonymous Coward | more than 6 years ago | (#22604616)

What UI advice to insure Quality Development?

What does that mean? Your unstated idea of quality? Your boss's unstated idea of quality? The slashdot groupthink's ill-begotten ideas of quality?

If you want something to crib off of, just to get this document-writing-task off your plate, the Apple UI guides are reasonable, as are many others, including the stuff you'd find in any HCI (human-computer interaction) text book, like "Designing Software" by Terry Winograd.

But if you seriously want a set of UI guidelines that will work for your users, you need some better requirements to start with, or you need to talk with your users (or with whomever is asking you to write this UI style guide).

Your Platform/Toolkit's HIG (2, Funny)

Sentry21 (8183) | more than 6 years ago | (#22604632)

Pretty much every platform (in this case, I'd count GNOME and KDE as 'platforms') will have a set of Human Interface Guidelines that will give advice on how to craft a usable interface that meshes well with native applications and provides a solid user experience. There's no one hard-and-fast style guide, though there are lots of examples of what NOT to do if you Google (see the User Interface Wall of Shame [mac.com] for one).

Get outside help (0)

Anonymous Coward | more than 6 years ago | (#22604634)

I've worked with dev teams my entire career on this stuff, mostly in SAS model businesses. I'll tell you, get outside help, it's more complex than a slashdot question (no offense). Visual and interaction design are related, but practically, are tracked & developed in different ways. Someone with experience doing both is what you're looking for.

Wrong question... (2, Insightful)

pla (258480) | more than 6 years ago | (#22604654)

I've been charged with making a specific user interface style guide for a suite of software by my employer. I'm not quite sure where to start

You don't know where to start because you don't work as a tech writer!

Tell your tightwad boss to pick someone more suited to the task - Even the weenies in Marketing can probably do the task better than an engineer (unless you just happen to have a background in technical writing, but it sounds like that doesn't fit into your job description/requirements).


Geeks can do anything - That doesn't always make us the best person for every job even tangentially related to "computers". If you want me to design a website, I can make it do anything HTML supports, but prepare for a color scheme that makes most people's eyes bleed...

Re:Wrong question... (0)

Anonymous Coward | more than 6 years ago | (#22604796)

but prepare for a color scheme that makes most people's eyes bleed...
HA!, very true, and indeed if there is someone else around the office that might be able to do this, then why not get the task to someone with a prior experience in the field

Re:Wrong question... (3, Interesting)

RobBebop (947356) | more than 6 years ago | (#22604868)

Tell your tightwad boss to pick someone more suited to the task - Even the weenies in Marketing can probably do the task better than an engineer (unless you just happen to have a background in technical writing, but it sounds like that doesn't fit into your job description/requirements).

When geeks design a Style Guide, it looks like this [ieee.org]. Simple, elegant, uncluttered.

When the weenies in Marketing design a Style Guide, the audience ends up trying to punch a psychedelic virtual monkey. Please don't suggest anything that would put marketing personnel in a position to produce anything that will guide me, thankyouverymuch.

Re:Wrong question... (1)

Talsan (515546) | more than 6 years ago | (#22606458)

Please don't suggest anything that would put marketing personnel in a position to produce anything that will guide me

Agreed. Marketing people are employed to build hype and help sell products. Most of them don't know squat about design.

Engineers can do a good job on design, but only when you slow down and force yourself to look at it from a user's perspective. We all use a lot of software, and you can probably come up with ideas very quickly about what annoys everyone you know. But you also have to think about the design aspects that your eyes just sort of pass over because they just work.

If you put marketing people in charge of design, well... Just look at the f*cking paper clip and puppy that Microsoft use. Does anyone seriously believe that an ENGINEER would ever consider that cute or useful?

Re:Wrong question... (1)

LaskoVortex (1153471) | more than 6 years ago | (#22605074)

If you want me to design a website, I can make it do anything HTML supports, but prepare for a color scheme that makes most people's eyes bleed...

MEMO FROM THE MANAGEMENT: You're out of excuses [colourlovers.com], now design that website!

Re:Wrong question... (1)

cdrudge (68377) | more than 6 years ago | (#22605192)

Even the weenies in Marketing can probably do the task better than an engineer
I'd argue that a pure marketing employee is almost the opposite extreme from why you wouldn't ask an engineer. I work as a web developer implementing my companies own design as well as those designed by outside marketing agencies. By far the most difficult designs are from the marketing company. While we try to beat it into their heads that print is not the the same as web nor is video the same as the web, many times they still treat them as the same.

Re:Wrong question... (1)

tknd (979052) | more than 6 years ago | (#22605472)

Tell your tightwad boss to pick someone more suited to the task

And obviously you're not a manager or you're not a good one. If managers lacked trust, confidence, and were not willing to challenge their employees, then their employees would only be as good as the first day they stepped in the door. Unfortunately or fortunately, most employees will stay for a good amount of time, therefore the better you can develop and train your employees, the more satisfied they will be with their job. If you simply sit at let them age (especially in the tech field) they are not improving and probably doing the same thing everyday. For some people, maybe that monotone job life is ideal, but considering the field (tech), I think in a majority of cases it will be the opposite (they want new challenging things).

In my personal experience, I have been challenged in a number of ways that were not explicitly stated in my job description which is your basic Software Engineer. Once I was tasked with defining a new process for managing internal documents. The current process was obviously flawed, and they wanted a better way of doing things. I did my analysis, found all of the issues, and came up with a few solutions. After meeting and presenting the results to my manager, I then asked "who is going to update the documentation, introduce the idea to everyone else, and etc?" And she looked at me and said "You are." Oh no! Shock! Horror! I can't sit behind my computer screen all day writing code! But since then, I have learned an awful lot about the company and more importantly, how to deal with people. To me that is more valuable than anything I could have learned in the technical field because guess what, the world is full of people and people call the shots. If you can't get momentum in other people, you are virtually hopeless in pushing changes in any organization.

Sure, my manager could have sat back in her chair, and picked the most qualified person to do the job and she may have saved money then. But by investing in helping develop and train me even though I would have been more costly, now I have the skills to do the same job as anyone else just as qualified would. That's a win-win: for me I gain new skills, for her she gains an improved employee at the "Software Engineer" rate. The only cost in the deal was time.

Re:Wrong question... (1)

dishpig (877882) | more than 6 years ago | (#22605624)

Exactly right. There is an entire field of expertise around UI design and technical writing (and no, they are not in the Marketing department) - what makes you or your boss think you can pick it up in a few hours and do a reasonable job of it?

On second thought, perhaps they're all busy doing application development...

Re:Wrong question... (1)

anticypher (48312) | more than 6 years ago | (#22605632)

I came here to say that. Except for the part about marketing, which is possibly the worst advice you could give. Marketing should only have minimal input, with neither approval or veto power over the project, or you will end up with neon blink tags and worse.

This is a job for someone who has prior experience in creating Human Interface Guidelines, who can create a set of guidelines for your company free from any plagiarism or theft of Creative Commons licensed material. There is a substantial amount of work to be done to create this, it isn't just another task to be tacked onto to your 80 hour weeks in the run-up to shipdate.

You have to tread carefully with CC licensed stuff. Just because it's on the internet doesn't mean its completely free for you to do with what you will. Does the original author want attributions? If so, then everywhere in your Interface Guidelines you must put attributions, something that may clutter up or cheapen your work.

The great thing about CC is that if you find someone who has published their work under CC and it mostly fits your project, you now have a good lead on hiring them to make a derivative of their work specifically for you. You've already seen the quality of their work, and you know they are modern and cool enough to use CC for their own purposes.

You need to go back to your boss and explain that a HIG book is not the responsibility of the geeks in IT or product development, it should come straight out of the marketing budget. You also have to balance the absolute requirement that marketing can't have any input other than basic guidance, because any radical changes to the HIG means scrapping the work to date and starting over. Tell your boss that the company needs to hire a professional for this important part of your project, and no IT person is qualified to do it.

the AC

Re:Wrong question... (1)

sbeckstead (555647) | more than 6 years ago | (#22607438)

Actually I don't think a Tech Writer is a good arbiter of an interface guide any more than a game store owner is a good game designer. A tech writer spends much of his time sorting out the tangle created by the programmer interpreting a spec written by the marketing department filtered through his boss coupled with the real world requirements of the hardware/software platform. And trust me that can be a mess. No I think that the Human Interface Guides of the various platforms are a very good place to start. Then find similar tools and use them. If none exist then you have the unique job of creating a paradigm. I do Ui's in VB and C++ and Python etc for a living but I don't mess with the art, that I leave to an artist. In Business software of course there isn't any art but you can add a bit of color to the mix. Remember the principle of least surprise. In other words what would the user be least surprised at that control doing.

Testing, testing, testing (4, Insightful)

Anonymous Coward | more than 6 years ago | (#22604682)

Some of the best input you can get is by giving the software to someone completely unfamiliar to the project, and ask them to accomplish 6 objectives that require them to navigate the application's interface. Ideally, you'll want them to be able to successfully complete those objectives with a minimal amount of time and hassle searching for the proper way to accomplish it. Have them identify trouble spots they ran into (icons confusing, unclear menu structure, etc). After reading over the input of uninitiated testers, you can fine tune your interface to be more intuitive.

I suffer from the problem when coding that I put menus and icons in places where *I* know where to find them, and that make sense to me. The problem is, I know the code from the ground up, so I know exactly what I'm doing - a huge bias compared to a new user who is trying the application for the first time.

Essentially, if your computer illiterate mother can figure your menu structure out, you are golden. A lofty goal that you'll probably have to cut some compromises into, but essentially the point is to keep it simple and make sure you account for your target audience.

Re:Testing, testing, testing (0)

Anonymous Coward | more than 6 years ago | (#22604800)

Also, I supposed I should have prefaced that post with: "File this under general UI development advice"

Re:Testing, testing, testing (1)

azrider (918631) | more than 6 years ago | (#22606372)

Some of the best input you can get is by giving the software to someone completely unfamiliar to the project, and ask them to accomplish 6 objectives that require them to navigate the application's interface.
The concept is called "Useability Testing". Do not stop with asking them to "accomplish 6 objectives". Match the objectives to the product requirements. Match the tester to the appication (if it is a Computed Aided Dispatch system, your primary testers should be dispatchers (I know, a novel concept ;-) ).

Provide a telephone for them to call the "Help Desk" when they have problems. Record the screen and keyboard. Document all of their problems. (LATHER)
Review the recordings, noting all problems encountered. Update any user documentation as needed. Note any areas where the requirements do not match the existing test product. Make any required modifications to the product. (RINSE)
Grab a new guinea pig. (REPEAT)

Yes, this can be expensive, but not as expensive as rolling out a product that does not do what is needed. If it is not what the target audience needs to perform their job (the reason you are doing this in the first place), you will fight an uphill battle what will only be "won" by management mandate. This will guarantee project failure. You will always need buy-in from the users for a project to succeed. Besides, once you have set this up once you can implement it whenever you want.
Remember, "Do it right or do it over"

Another resource: (1)

azrider (918631) | more than 6 years ago | (#22606430)

Why Software Sucks...and What You Can Do About It
Author: Platt, David S.
ISBN: 0-321-46675-6

Get it and read it.

"Quality" is not an adjective! (1)

Fear the Clam (230933) | more than 6 years ago | (#22604732)

In addition to just documentation, what other UI advice can Slashdot readers offer in order to ensure quality development?

Do you mean "quality development" as how to develop of some sort of measure of quality, or do you simply mean development that fails to suck?

Have I got a job for you (3, Funny)

iliketrash (624051) | more than 6 years ago | (#22604776)

"I'm a software developer but have not had any formal training in UI design or look and feel."

That would make you the perfect Microsoft employee.

Re:Have I got a job for you (1)

rdavidson3 (844790) | more than 6 years ago | (#22605628)

To be fair, Vista has a gorgeous interface. Very nice on the eyes, but leaves a lot to the imagination functionally.

Just Get An Interaction Design Textbook (2, Informative)

Tech Librarian (1248708) | more than 6 years ago | (#22604798)

I would suggest going out an getting a book on Interaction Design, such as that by Sharp, Rogers, and Preece. If you look over the diagrams and the chapters you should get the gist of it. This book is used in introductory graduate Human-Computer Interaction courses.

Curly Brace OK/Cancel (2, Interesting)

hansamurai (907719) | more than 6 years ago | (#22604858)

Choose a curly brace style and stick with it! Oh, this is UI styling we're talking about...

Try this HCI web comic, I don't think it is updated anymore but there's lots of great archives:

http://www.ok-cancel.com/ [ok-cancel.com]

Don't re-invent the wheel (2, Insightful)

MSTCrow5429 (642744) | more than 6 years ago | (#22604866)

Unless the software suite is the only thing the user is going to see, and not the underlying OS or any other software, you should just follow the guidelines for the OS or desktop environment. Otherwise, you get a schizophrenic result that clashes with everything else, leading to user confusion and frustration. If you're designing from scratch, I suggest reading Raskin's "The Humane Interface," and using that as a baseline. Don't read the Apple user guidelines. Unless you're used to a Mac, they don't make sense.

Re:Don't re-invent the wheel (1)

iangoldby (552781) | more than 6 years ago | (#22606266)

I can only amplify what the parent poster has said.

Follow the design style guide of the hosting desktop environment.

If you are developing for Windows, use Microsoft's own guidelines [microsoft.com].

If you are developing for Mac OS X, use Apple's (link already given by someone else).

If you are developing for Gnome, use the Gnome guidelines.

You get the general idea. Also, don't invent your own controls/widgets unless you Really Have To.

If you are writing a cross-platform application, it's a bit more difficult. Find an application framework that adopts the user interface guidelines of the hosting environment, so that you don't have to do the work yourself. (This is left as an exercise for the reader...)

Starting points for search (1)

ODBOL (197239) | more than 6 years ago | (#22604912)

A lot depends on the detailed nature of the applications in question. Here are some starting points for hunting down information.

  1. Other posters already mentioned MacIntosh and Tufte.
  2. Phil Greenspun's articles: http://philip.greenspun.com/writing/ [greenspun.com]
  3. Any Browser Campaign: http://www.anybrowser.org/campaign/ [anybrowser.org] (even if your application isn't on the Web, the principles are similar, particularly for accessibility).
  4. Study the Model/Controller/View pattern from the software pattern community. Sorry I don't have a specific pointer. Keep in mind that the 3-part pattern is probably a mistake for most purposes: Controller and View usually have to be combined, because the boundary changes between levels of abstraction. This pattern doesn't have to do with how the interface looks to the user, rather it has to do with structuring software so that you have a prayer of controlling the user interface part of the design. Many projects accomplish this pattern (without necessarily knowing about the pattern idea) by organizing work into a function library and a user interface exercising that library.
  5. A key principle (not sure where it's documented) is orthogonality. At some level of design (definitely at the library level), it's very important to identify the fundamental operations that make sense conceptually (in the previous item, these are the natural operations of the Model). "Orthogonality" just means that each fundamentel operation should be essentially independent of the others. Next, make sure that you never lose access to these fundamental operations. Now, you can design combinations of operations to satisfy the most common user needs, without leaving frustrating gaps where a user with a slightly unusual need cannot perform the right operations, because they are only available in unwanted combinations.
  6. Whenever you provide a level of operation that you think makes things simple for the user, try to leave some way to get a transparent view of the technical level below it, in case your notion of "simple" isn't always quite the right one. E.g., Apple screwed this principle up very badly in Garage Band, which hides the individual sound files totally from any user who relies on the Mac's views of the file system. Only through a Unix terminal interface does one discover that the "project" is a directory, with lots of files in it. An early version had a bug, in which the "Save As" button did not actually save a file. There was no way to discover this until it was too late (and I lost one of my best audition recordings to this bug, and resolved never to touch Garage Band again).
  7. Which reminds me of one of the best ways to learn good interface structure: observe lots of bad examples. They are plentiful. The downside is you can spend infinite time on this survey.


Have fun!

An 8th principle (1)

ODBOL (197239) | more than 6 years ago | (#22605052)

8. Single data entry. Sometimes this happens without thinking, but if you blow it badly, it creates havoc. Each piece of information required from the user should be entered precisely once in precisely one context (per interaction---the context can be different depending on what else the user has done, but it shouldn't vary according to accidents of the program execution). Every sufficiently complex system starts to drift away from this principle, so that a single change requires a user to hunt down several different entries of that change, which nobody can do consistently correctly. Then, it is outrageously hard to find the particular wrong entry that's causing a particular problem.

Of course, this doesn't rule out independent re-entry for the purpose of consistency checking, such as the re-entry of a password. But that sort of re-entry needs to be followed immediately by a consistency check and correction.

Edward R. Tufte (1, Informative)

Anonymous Coward | more than 6 years ago | (#22604932)

Google Edward R. Tufte. "The Visual Display of Quantitative Information" is priceless and general enough. Also "Visual Explanations: Images and Quantities, Evidence and Narrative" is a nice companion. These should be on every designers book shelf.

For me, it's easy (1)

quincunx55555 (969721) | more than 6 years ago | (#22604970)

Just pretend you are the user you are writing for. If you have no idea what that type of person is like, find someone that does (sales, marketing, actual customer, etc).

Ask your self (or the other person), "What do you want to do" (over and over again, in different contexts). There are so many times we get wrapped up in the technology to create a solution that we start to build the UI based on it. The UI should be based on the desires/needs of the user. Why else would the software be developed? Taking this stance, when done with honesty, will usually lead to a simple and practical design.

This can get complicated as you may assume the role of a new user, and then someone that's an expert. Or someone that bought the software because they wanted it vs someone that is going to hate it just because their boss told them they need to use it. They will have different needs, that tend to contradict (simplicity vs configurability for example).

Sometimes it's quickest to start with pen and paper. Easy to create, easy to throw away, save what you need by scanning it in, then use that as the starting point for coding the UI.

If that's still too much of a challenge, involve other departments (QA, Tech Support, Documentation) and get their input. As far as "design guide", there are obvious conventions being used... follow them. Don't use checkboxes like radio buttons, don't use drop-downs to open a dialog box, etc.

If you get stuck in an area, start opening up interfaces from other software that has something similar and see how they do it. Then ask yourself if how they did it is "correct", or best, for your customer(s).

Good Luck!

Start with Facebook... (2, Insightful)

rueger (210566) | more than 6 years ago | (#22604988)

... and ignore everything that they do.

Then work with real users and find out what they want the app to do, how they want it to do it, and assess what their knowledge and skills levels are. In all likelihood you are entirely the wrong person to judge what's appropriate for end users.

Free Desktop Standards (0)

Anonymous Coward | more than 6 years ago | (#22605158)

Wasn't there an effort to concert free desktop user interfaces? There are standards guidelines on that page as far as I can remember...

About Face Is A Good Read (1)

Snocrash23 (1163813) | more than 6 years ago | (#22605288)

I'm not a UI Designer but I play one on TV (2, Informative)

sconeu (64226) | more than 6 years ago | (#22605376)

I'm a software developer but have not had any formal training in UI design or look and feel. I'm looking for something more than just "keep it simple, stupid."

Then your proper response is, "Are you sure you want me to do this? I have no training in this area."

And put it in writing as a CYA.

HCI (1)

gilesjuk (604902) | more than 6 years ago | (#22605448)

You need to read up about Human Computer Interaction.

Also, the guidelines for a web application or mobile application will be different to that of GUI application.

You should read up about accessibility, should your application be used in government organisations then it may often need to be able to be used by people with eyesight or mobility defects.

Important points, never rely on colour to differentiate things. Not everyone has reliable colour vision.

Involve end users where possible.

Read Jacob Nielsen's opinions, don't take them as gospel but he does have some good points.

http://www.useit.com/ [useit.com]

Stick to the guidelines of the OS you are developing the application for. Use common well established key shortcuts.

scenarios (1)

utnapistim (931738) | more than 6 years ago | (#22605470)

I've had no formal training in GUI design either, but I've found that making a few useful scenarios works pretty good (although it takes a bit of time).

To do so, try to imagine a few "typical" users for your application, and go down to enough details about them, until you have a clear image of their personality. It's pretty hard to do first (sounds easy, until you actually start writing stuff down, then you block).

The idea while doing this is to come to different aspects in usability, not in features. That would allow you to (hopefully) come to a good understanding of which tasks are most important and how to prioritize them.

I believe Joel Spolsky described this method at some point but I'm too lazy at the moment to search for the link.

Fluid (1)

frequnkn (632597) | more than 6 years ago | (#22605790)

The Fluid Project is just getting off the ground, and it is focused on higher ed, but their wiki might be a good place to hang out, if you want to talk to serious HCI geeks. I've talked to some folks at conferences about it, and they have some hardcore research components to their work - you know, users, and researchers, and people writing down what happens :-)

From http://fluidproject.org/ [fluidproject.org] ---

"Fluid is a worldwide collaborative project to help improve the usability and accessibility of community open source projects with a focus on academic software for universities. We are developing and will freely distribute a library of sharable customizable user interfaces designed to improve the user experience of web applications"

general reading under interface development (1)

yaihoolood (713194) | more than 6 years ago | (#22605832)

If you're interested in the theory and understanding good interfaces: The Design of Everyday Things by Donald Norman The Inmates Are Running The Asylumby Alan Cooper With those books in mind, *then* use the HIGs :) ~Lee

Inmates are running the Asylum (1)

CNTOAGN (1111159) | more than 6 years ago | (#22605956)

Someone already mentioned the About Face books (The Essentials of Interaction Design), but to really get a good start on what you need to do is read kind of the precursor to those books, by Alan Cooper: The Inmates are Running the Asylum http://www.amazon.com/Inmates-Are-Running-Asylum/dp/0672316498 [amazon.com]

It gives a good case for why YOU shouldn't be writing User interface guidelines and why a design specialist - who is a stakeholder and needs to own the project - should be.

Interface Design simply put. (0)

Anonymous Coward | more than 6 years ago | (#22606102)

Hi. I suggest a book written by Alan Cooper, the designer of the Visual Basic user interface, lo those many years ago.
His approach to explaining interface design and how to make it user friendly is a key work in my mind. He writes in a relatively non-technical way, but he expects the reader to understand the basics.
Hope this helps.
MarshG.

http://www.amazon.com/About-Face-Essentials-Interface-Design/dp/1568843224/ [amazon.com]

Wisdom from the Design of Everyday Things (1)

Nerdposeur (910128) | more than 6 years ago | (#22606126)

The Design of Everyday Things is a great book, considered a classic. It covers basic things like doors and telephones more than GUIs, but it helps you think in the right direction.

One principle that stuck in my mind is that you should make things as obvious as you can - if you've got four heating elements on a stove, arranged in a square, then arrange the knobs that control them in a square and it's obvious how it maps. If you put the knobs in a straight line, you have to label them and the user has to stop to read the diagram.

A second principle is that you should make the penalty for screwing up as low as possible.

Imagine the worst possible user interface: it's easy to click the wrong button, and clicking the wrong button does something disastrous. Now strive for the opposite: it's obvious which button is right, and clicking the wrong one doesn't do anything that can't be easily undone.

Easier said than done, but just imagining the good design makes me feel less stressed.

Accessability Guidelines for Developers (1)

rbenech (97413) | more than 6 years ago | (#22606234)

IBM has a great checklist for Accessability of different UI implementations (web, app, lotus notes).

http://www-03.ibm.com/able/guidelines/software/accesssoftware.html [ibm.com]

Understanding Accessibility

If you are new to accessibility, review "Understanding accessibility" before completing the checklist or contacting the Human Ability and Accessibility Center for help.
IBM software accessibility checklist

Use this checklist for:

        * general software products and applications that have a user interface
        * software tools, this applies to both the user interface as well as the output of the tool
        * Java 1.1.x applications that use standard AWT components and are designed to run only on Windows platforms
        * software used by system administrators to control and monitor servers or other remote equipment
        * Eclipse applications written with Standard Widget Toolkit (SWT) controls. Note: SWT controls do not use the Java Access Bridge.
        * software with a command line interface

Last updated May 28, 2003. Techniques pages, accessed via the link in each checkpoint, may contain more recent updates. Be sure to review the techniques pages for the latest accessibility guidance.

Tango Icon Community (1)

pixelfood (973282) | more than 6 years ago | (#22606244)

I found the Tango Icon community when I needed to develop icons for my application. I joined the mailing list, and they always have good suggestions about style. A lot of the design principles they talk about transcend icons. Even though I don't have any formal training in UI design either, I have picked up a lot of tips on how to give the UI a systematic, cohesive style.

UI Design for Programmers (1)

eddeye (85134) | more than 6 years ago | (#22606292)

I highly recommend Spolsky's User Interface Design for Programmers [amazon.com] as a place to start. It's short and to the point, with about a dozen guiding principles to make your UI practical. It's a light and fast read, yet substantial enough to get you off and running.

AC's PD style guide (0)

Anonymous Coward | more than 6 years ago | (#22606622)

1) All buttons need to have an accurate and useful tooltip
1.5) ALL AREAS AND MENUS must respond correctly when F1 is pressed, jumping to the application help file's main screen is not correctly, jump to the relevent area
1.75) the help file must be up to date, always, NO EXCEPTIONS
2) nothing done more than once per day shuld be more than 2.5 clicks away from where the user will normally be when it needs to be done.

3) pauses for sub menus to open automatically count as half a click
4) pauses for a subment to open from withing an existing submenu(such that moving the mouse will close the parent menu) that opened the same way counts as 500 clicks
5) use environment and industry standard keyboard shortcuts wherever possible
6) flay any employee who implements a function which can destroy or fail to save data on any single F-key or any standard keyboard shortcut (i.e. ctrl-c to CLEAR, ctrl-z to CLOSE, F1 to return to home screen)

Negative? (1)

19061969 (939279) | more than 6 years ago | (#22607342)

I don't want to sound negative but (and assuming this is a commercial gig) you may need to get someone who knows how to design UIs in to do the job. After all, would you hire a HCI specialist to produce C code? It's good that you want to learn about UI design (and best of luck), but it's a surprisingly large area with lots of work being done (even so called specialists aren't aware of the research that goes on).

Reading books and style-guides is a start but then so is employing programmers with a basic certificate in programming. If you had some difficult coding to do, would you employ a UI designer who had read a dummies guide to C to do the job?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...