Beta
×

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!

Ask Slashdot: Should You Invest In Documentation, Or UX?

timothy posted about 2 months ago | from the ask-your-users dept.

Software 199

New submitter fpodoo writes "We are going to launch a new version of Odoo, the open source business apps suite. Once a year we release a new version and all the documentation has to be rewritten, as the software evolves a lot. It's a huge effort (~1000 pages, 250 apps) and it feels like we are building on quicksand. I am wondering if it would be better to invest all our efforts in R&D on improving the user experience and building tools in the product to better help the user. Do you know any complex software that succeeded in avoiding documentation by having significantly improved usability? As a customer, how would you feel with a very simple product (much simpler than the competition but still a bit complex) that has no documentation?"

cancel ×

199 comments

Sorry! There are no comments related to the filter you selected.

Yes. (2, Insightful)

Nimey (114278) | about 2 months ago | (#47671907)

en tee

Re:Yes. (2)

disposable60 (735022) | about 2 months ago | (#47672501)

Hos this a Troll and the False dichotomy, which says the same thing, Insightful?
/ I know, don't complain about moderations, but some times ...

False dichotomy. (5, Insightful)

aeschinesthesocratic (1359449) | about 2 months ago | (#47671929)

Invest in both.

Re: False dichotomy. (1)

Anonymous Coward | about 2 months ago | (#47672179)

I test with users for a living, and I agree that this is a false choice. You should have both. I would say however, that a big source of frustration for users when they need to dig into the manual is digging thru to find what they really want to do. The UX should support ease of use for most people. The manual should focus on everyone else. (Possibly supported by a quick-help guide for the really basic user.)
YMMV

Re: False dichotomy. (2)

Narcocide (102829) | about 2 months ago | (#47672205)

I think what you're really getting at is that UX should not omit attention to the UX of the manual itself.

Re: False dichotomy. (3, Insightful)

Anonymous Coward | about 2 months ago | (#47672857)

"you're not wrong but you're wrong", ofc the manual should be userfriendly but even the best manuals are often ignored by the users, tests have shown that even with very simple (that is, easy to read, understand and apply) documentation, in a population you will find two groups of users - the group that understands the interface and uses the manual, and the group who turns to members of the first group for help at the slightest frustration.

Re: False dichotomy. (2)

CanHasDIY (1672858) | about 2 months ago | (#47672665)

I would say however, that a big source of frustration for users when they need to dig into the manual is digging thru to find what they really want to do.

To which I add the caveat, if the documentation SUCKS , ie poorly written/laid out/indexed, it's an even bigger source of frustration. Like, "I would really like to throttle the idiot who got paid to write this offal, preferably with a Franklinator [youtube.com] " kind of frustration

Re: False dichotomy. (3, Insightful)

MrBingoBoingo (3481277) | about 2 months ago | (#47672817)

And then there's the matter that a number of people who really benefit from good documentation are developers. Documentation helps describe to your team what these chunks of code are supposed to do and in the long run can help to avoid the problem where "new features" end up poorly replacing popular well used features.

Re: False dichotomy. (2)

macs4all (973270) | about 2 months ago | (#47672745)

I test with users for a living, and I agree that this is a false choice. You should have both. I would say however, that a big source of frustration for users when they need to dig into the manual is digging thru to find what they really want to do. The UX should support ease of use for most people. The manual should focus on everyone else. (Possibly supported by a quick-help guide for the really basic user.) YMMV

I have been incorporating "online help" available directly from the application. These "help" buttons are linked to Bookmarks in a MS Word -> PDF document that is located on an Amazon S3 Server. The nice thing is, unlike your typical "Help File", which tend to have "explanations" that are circular, or that refer to even MORE gobbledegook, this is the "real" documentation, "opened" to EXACTLY the relevant Page.

Personally, I think this is a much better alternative to a simple "here's your PDF, have at it" (they can still save-as the pdf for offline perusal), or even worse, the usually all-too-brief typical "CHM" file-style "Help" docs.

Re: False dichotomy. (1)

corychristison (951993) | about 2 months ago | (#47672849)

To expand on your idea there... why not have it organized in a wiki, and link to the relevant wiki article?

I understand having an offline manual is a godsend at times, but I prefer an online resource vs a PDF. This is my personal preference, though.

Re: False dichotomy. (1)

Sarten-X (1102295) | about 2 months ago | (#47672751)

And we have a winner!

Most hardware I buy these days comes with a quick-start guide to just make the thing work. It shows users the basic installation they need to get something working, so they can learn on their own. A well-designed product will encourage such self-guided learning, as it empowers the user.

However, not everything is suitable for a quick-start guide. It's not the right place for preferences, advanced settings, unusual configuration, or alternative use cases. That all belongs in the manual which can then, except for the troubleshooting section, be designed with the assumption that the user has a basic working system and has used the product successfully.

Re:False dichotomy. (5, Funny)

ShanghaiBill (739463) | about 2 months ago | (#47672359)

Invest in both.

You should go into management. Then you can bring world class excellence to any organization, simply by making everything a top priority.

Re:False dichotomy. (1)

crashumbc (1221174) | about 2 months ago | (#47672535)

It works for my company!

(well not really but they keep trying to make everything a priority anyway )

Re:False dichotomy. (1)

sexconker (1179573) | about 2 months ago | (#47673001)

Invest in both.

Fuck no.

Documentation is worthwhile.

UX is willy-nilly bullshit 99% of the time that you'll have to revisit over, and over, and over with each new fad. Any changes to "UX" shit will also force you to unnecessarily rewrite half of your documentation.

You're doing it wrong. (5, Insightful)

seebs (15766) | about 2 months ago | (#47671939)

If you have to rewrite all your documentation, you've done something horribly wrong.

Suggestion: Consider focusing on stability for a while, because stability is a huge win for user experience.

Re: You're doing it wrong. (5, Informative)

Fabien Pinckaers (3785215) | about 2 months ago | (#47672033)

We actually have four documentations: developers, community (how to contribute), designers (how to develop theme), users (accountant, crm, point of sale, ecommerce, ...) The first three are stable enough and we will for sure invest in a great documentation. But the latest, the business apps, will evolve a lot in the coming months as they are plenty of areas to improve. My question relates only to the user documentation. For developers and designers, we more or less freeze the api/interfaces.

Re: You're doing it wrong. (1)

Will.Woodhull (1038600) | about 2 months ago | (#47672173)

If the UX is really good, you can let the user documentation slide somewhat. You can also think about presenting the basic user docs as a wiki and encouraging your user base to expand and expound on that. Editing user contributions will be a heck of a lot easier than writing from scratch (you can start things off by just publishing an outline of what needs to be covered).

Re: You're doing it wrong. (5, Insightful)

seebs (15766) | about 2 months ago | (#47672217)

I am pretty sure that that is exactly the wrong thing, then, because the entire point of "business apps" is that people are supposed to be able to build a stable operation on them. If you are changing things so much that you have to rewrite the documentation entirely, that means you are changing them so much that anyone using the software must completely redo their entire process, retrain anyone using the system, and so on.

That's way too much change. If you are changing things enough that you are rewriting documentation every release, then you are not "evolving".

Re: You're doing it wrong. (4, Insightful)

BaronM (122102) | about 2 months ago | (#47672227)

As an admin/IT manager, what I'd like to see is:

1. Meaningful, specific error/log messages when something goes wrong.
2. Accurate documentation of what those errors mean.

Most end-users won't read long or complicated documentation, business application in particular almost always require end-user training on how to use them --as implemented-- and --in accord with company practice/policy--, so generic docs are of limited value.

On the other hand, I sincerely miss the days when I could actually expect proper error codes and documentation thereof, and having that available would certainly influence a purchasing decision on my part.

Mod parent up! (4, Interesting)

khasim (1285) | about 2 months ago | (#47672423)

As an admin/IT manager, what I'd like to see is:

1. Meaningful, specific error/log messages when something goes wrong.

Do this.

And make the error reports unique. No more "an unexpected error has occurred". Even "purple-monkey-dishwasher" is better than that. Make it easy for your users to report real problems to your developers. And that means making each error unique enough that the developers can search the code for it.

And have someone spend some time sorting through your forums (make sure you have forums) who can move threads and messages around while still maintaining the links to them. So someone with a "purple-monkey-dishwasher" error can see the other posts about that WITHOUT having to dig through unrelated "vitamin-can-hook" errors. Sortable by version. And by date.

Re:Mod parent up! (0)

Anonymous Coward | about 2 months ago | (#47672655)

> So someone with a "purple-monkey-dishwasher" error can see the other posts about that

I worked back-line support on a now long-forgotten HPC unix kernel.
We added code to the kernel panic handler to hash the stacktrace.
We still printed out the entire stacktrace because that was useful to debugging the error, but printing a unique "panic code" made it dead-simple for anyone to do a search and find any other reports from other users who had the same kernel panic.

Re: You're doing it wrong. (1)

i_ate_god (899684) | about 2 months ago | (#47672589)

One of the benefits about the teams I work with is just that, we're TEAMS.

So if I'm working on my part of the project, and something breaks from the other teams and the error is non-obvious, a bug report is filed saying not only how the error was generated, but that the error message itself is not clear to me and needs to be fixed.

QA has also been trained just enough to know when an error message doesn't make much.

Re: You're doing it wrong. (4, Interesting)

ravyne (858869) | about 2 months ago | (#47672323)

Having a well-thought-out, consistent, orthogonal, and to-the-extent-possible obvioius UI can go a long ways toward the user experience, bring relevent information nearer to the user, and even make the documentation easier to write -- but even having achieved that ideal, UI/UX cannot and will not substitute for documentation.

At the end of the day, your users have a business goal, and you've sold them on the idea that your software package will help them achieve it better and more easily than other solutions. You sell solutions and solution components, but you also sell 'better' and 'more-easily'. Documentation is necessary, no amount of UI will take you from splash screen to solution whilst navigating a large set of outcomes and a series of interdependent choices.

DO provide UI reference, but scenario-driven documentation is your users' greatest need.
DO automate common, simple tasks to the extent possible.
DO make doing the right thing easy, and wrong or dangerous things hard.
DO bring the most relevant information into the app in abbreviated form (apply the 90/10 rule)
DO link the UI to relevant documentation.
DON'T get hung up on covering every possible scenario (again, 90/10 rule)
DON'T believe that a perfect UI avoids the need for documentation.
DON'T try to bring all the documentation into the UI.
DON'T rely on your own intuition about what's common or difficult for users, ask them or collect the data.

Re: You're doing it wrong. (1)

bill_mcgonigle (4333) | about 2 months ago | (#47672991)

Having a well-thought-out, consistent, orthogonal, and to-the-extent-possible obvioius UI ...
DON'T rely on your own intuition about what's common or difficult for users, ask them or collect the data.

You have it exactly right, but notice the AskSlashdot talked about UX, not UI.

UI is a science, there are methods, data, studies and books. UI people are rare and valuable.

UX people tend to add more whitespace, transparency and animations, making the product look more fashionable (" n++.0" ) for whichever n your developers are currently building.

If there's no UI person in sight, documentation is probably his best choice.

Re: You're doing it wrong. (1)

unrtst (777550) | about 2 months ago | (#47672551)

So you have documentation for developers (API), community (code contributes), and designers (themes), but the problem area is for users.

IE. you are providing docs for the very smallest percentage of users, and leaving the vast majority of users without documentation.

That seems to be fairly common, but it's completely backwards. Similar to optimizing administration processes while end user processes get ignored because they get paid less or are simply not as well connected.

Come up with some way to document while making coding changes for user facing parts. That's the part that should be documented, and keeping it current is much more important than your API docs (though those are most likely autogenerated already, and thus up to date). Make documentation part of the cost of development so that expectations in productivity don't get way off kilter (ex.rewriting 1000+ pages at release time... it's just not maintainable that way).

Re: You're doing it wrong. (0)

Anonymous Coward | about 2 months ago | (#47672607)

What you're really asking is whether you can make the software "intuitive" enough so you can do away with the help files.

You should know the answer to that by now. In lieu of a single word answer:

Let me point out that we got windows, helldesks, "uneducatables" and frustrated people everywhere. You may know that a fancy dev saying is "the only thing that's intuitive is the nipple, the rest is learned." Don't let a new mom hear you say that, for she'll say that not even the nipple is "intuitive". That is, the intuitivity idea doesn't work very well. Never has, but that didn't stop a lot of people believing in it anyway, and wasting quite a lot of code trying to make it work for real this time. (Hello clippy!)

Just like how making everything a GUI was once thought to be the silver bullet of UX design. Because, you know, you can just see the buttons sitting there and all you have to do is to click them. (Compare cow clicker.) Consider that even windows now finally has its customary bad reinvention of a command line interface beefed up enough that it'll let you run what passes for its servers without GUI.

So the bottom line is this: Even if most people can't be bothered to read the fine manual, you still should make sure you have good, accurate, and readable documentation. If nothing else you'll make the helldesk's job easier--they can read it and step your idiot users through it over the phone. You'll also want to read up on Fred Brooks, as he has some useful things to say about documentation too.

Re: You're doing it wrong. (1)

Chris Mattern (191822) | about 2 months ago | (#47672833)

.My question relates only to the user documentation. For developers and designers, we more or less freeze the api/interfaces.

Wow. So your excuse is that you're only dropping this massive rewrite on the audience least able or inclined to absorb it. Way to go.

UX (3, Interesting)

Raven42rac (448205) | about 2 months ago | (#47671963)

No one reads documentation.

Re:UX (1)

Don Huff (3785261) | about 2 months ago | (#47672955)

That said, users do look to get answers. I am a fan of online documentation that is broken down into a hierarchy of function and that identifies features by available version, so that there is really only one set of documentation. Your program may contain direct links into the documentation hierarchy, or the user can build their own set of most useful browser bookmarks. If your documentatiion server can allow users to add their own examples and explainations this can be very valuable (some times not so, too.)

Not all documentation is giant documents (4, Insightful)

penguinoid (724646) | about 2 months ago | (#47671971)

Have every menu command give it's keyboard shortcut, either next to the item name or as a tooltip. This is superior to a giant list of keyboard shortcuts. Wherever you can eliminate documentation by improving the user interface or integrating the documentation with the user interface, do so. However, there are some things that simply belong in separate documentation.

Re:Not all documentation is giant documents (2)

pavon (30274) | about 2 months ago | (#47672247)

Absolutely. There are many advantages to this approach:
* Users can get info they need more quickly as they are already in the correct context to get help on that feature, and don't have to search a document.
* Users are more likely to use integrated help than a huge user manual, saving you support time.
* It is easier to enforce a policy of updating documentation when you update code.

The only thing your separate documentation needs to cover are high-level concepts of the application, and common HOWTOs. If you must have a monolithic reference document, then use a system like docbook that generates HTML and PDF, and integrate HTML help into your application.

Of course this is assuming that these are GUI apps. Server apps or anything that needs configuration outside of a GUI must have full reference documentation.

Re:Not all documentation is giant documents (0)

Anonymous Coward | about 2 months ago | (#47672647)

Of course this is assuming that these are GUI apps. Server apps or anything that needs configuration outside of a GUI must have full reference documentation.

All you need are properly written man pages and a wiki-style manual for installation, configuration, and upgrading information along with a section to record the configuration of your application or system. This is the approach I took with the technical documentation for the servers, both physical and virtual, and it is much better.

Re:Not all documentation is giant documents (1)

Anonymous Coward | about 2 months ago | (#47672605)

Have every menu command give it's keyboard shortcut, either next to the item name or as a tooltip. This is superior to a giant list of keyboard shortcuts. Wherever you can eliminate documentation by improving the user interface or integrating the documentation with the user interface, do so. However, there are some things that simply belong in separate documentation.

"But the UX team just took away all the menus so as to make more room for a more elegant flat UX! They did this because telemetry told them nobody was using the Smart Auto-Rearranging menus from two years ago."

Invest in UI stability, not UX fashion, and maybe then the documentation won't have to be rewritten, with every screencap retaken, every fucking sprint.

Open Source It (4, Funny)

Anonymous Coward | about 2 months ago | (#47671981)

And just make a wiki and the community will do all your work for you.

Re:Open Source It (0)

Anonymous Coward | about 2 months ago | (#47672041)

Humorist.

When every feature undocumented (4, Insightful)

sinij (911942) | about 2 months ago | (#47671987)

When every feature is undocumented, how do you expect to attract new users or introduce new features?

Plus, there is no such thing as intuitive GUI, the best you could possibly do is to have shallow learning curve.

Re:When every feature undocumented (1)

davidwr (791652) | about 2 months ago | (#47672379)

Plus, there is no such thing as intuitive GUI

I dunno, I'd say it's fair to call the user interface at most ATMs and credit-card machines intuitive. Granted, some of those user interfaces aren't graphical, but some are.

To put it another way, the learning curve on these things is so shallow that if there's a difference between its shallow learning curve and what you would call an "intuitive GUI" I'm not seeing it.

Re:When every feature undocumented (3, Interesting)

Lunix Nutcase (1092239) | about 2 months ago | (#47672467)

That's interesting because I see people on a daily basis fumbling with the debit/credit machines at checkouts. Even with basic things like swiping their cards. A big pain point is also becaue each one for each store chain has to be different in unnecessary and inconvenient ways.

Re:When every feature undocumented (1)

Obfuscant (592200) | about 2 months ago | (#47672789)

That's interesting because I see people on a daily basis fumbling with the debit/credit machines at checkouts.

If you stopped standing near the line trying to shoulder surf their PINs you wouldn't see so many.

Even with basic things like swiping their cards.

That's poor design of the hardware, not the software. When you have to figure out where the magstripe is on the card and then where the reader is so you get the right orientation, you're bound to get it wrong. The ATMs I use that have a simple slot to push the card into, I never get wrong. Card comes out of wallet with me holding the end that goes into the machine last. Very simple.

But there are, indeed, intuitive GUI programs. They're the ones you never think about. The ones that you remember are the stupid ones. For example, any GUI where you click on a TEXT LABEL to a menu or dropdown to do something. A label should label what the button is, not be the button itself. One program I use requires me to click on a red label to fix whatever the red thing is.

An example of one of the most egregious GUI offenders is ... Windows Media Center. If you want to scroll left or right on something (like the program guide so you can see what is on later today) you have to roll over JUST the right spot on the screen and a magical left or right arrow (less than or greater than characters) will appear. Same with up and down. And if you are looking through the list of recorded programs, if you dare keep the cursor over one program too long the entire list will shift to the left so that item is the leftmost. Even if it started as the rightmost. That means you can put your cursor over a program in anticipation of viewing it, pause to read the description to make sure it is the right one, and just before you click on it it will run away and you'll be clicking on the wrong thing.

Poor documention = Poor perception (3, Interesting)

NotDrWho (3543773) | about 2 months ago | (#47672025)

If you want your software to be taken seriously by anyone outside of a tiny niche, bite the bullet and get a decent technical writer to write decent documentation. Sloppy documentation is equated (usually rightly) with sloppy coding, sloppy security, and an overall sloppy effort.

Re:Poor documention = Poor perception (1)

reikae (80981) | about 2 months ago | (#47672493)

If this is true, where does the widespread notion that nobody reads the documentation come from? Do customers demand documentation for the sake of having it? Or maybe I'm not the only one who reads documentation after all. (Well, I do read it more often than not :-))

Re:Poor documention = Poor perception (1)

CanHasDIY (1672858) | about 2 months ago | (#47672695)

If this is true, where does the widespread notion that nobody reads the documentation come from?

Web comics, stereotypes, and bad jokes.

I only wish I was kidding.

No doc (4, Insightful)

Oligonicella (659917) | about 2 months ago | (#47672037)

As a developer and a user I absolutely *hate* apps with no documentation. None of the apps I see on your linked page are primitive enough to stand without. Actually, nothing more complex than say... well, nothing.

Re:No doc (1)

sinij (911942) | about 2 months ago | (#47672153)

Exactly. Even as intuitive "interface" as bathroom signs require explanation at least one time, and even as widespread as bathroom signs, they still do not have uniform notation.

Re:No doc (1)

ThatsDrDangerToYou (3480047) | about 2 months ago | (#47672243)

Exactly. Even as intuitive "interface" as bathroom signs require explanation at least one time, and even as widespread as bathroom signs, they still do not have uniform notation.

I know, right? I have done a lot of work on bathroom signs, but the jerks keep painting over them..

Re:No doc (1)

sinij (911942) | about 2 months ago | (#47672371)

This is because you don't properly encapsulate interfaces and don't adequately document mounting and unmounting process.

Re:No doc (1)

CanHasDIY (1672858) | about 2 months ago | (#47672711)

Exactly. Even as intuitive "interface" as bathroom signs require explanation at least one time, and even as widespread as bathroom signs, they still do not have uniform notation.

I know, right? I have done a lot of work on bathroom signs, but the jerks keep painting over them..

Well, if you'd stop putting them on the door to the kitchen...

Depends on the target: (3, Interesting)

fuzzyfuzzyfungus (1223518) | about 2 months ago | (#47672039)

If something is an end user product, it appears to be sad but inevitable that nobody RTFM anyway, so you are probably better off doing everything you can to make it actually work when prodded by the clueless. Try to make sure that it's all point-and-drool simple(if it is possible to back yourself into a 'mysteriously doesn't work, provides meaningless or nonexistent clues as to why' corner; an elegant way to roll back is nice).

If the idea is that the product will be set up and administered by the customer's IT minions(internal, contract, or purchased 'as a service'), then Please, Please, Please document. IT minions are largely innured to the suffering of merely bad, hostile, and unintuitive software; but they are the most likely to need to know how things fit together, where they may need to bodge some shim together and keep an extra close eye on things, and so on. They won't like it; but they'll like it a whole lot more than an equivalent product where they need to deploy a mixture of reverse-engineering and pure mysticism because the system is a total black box.

Target market? (1)

gurps_npc (621217) | about 2 months ago | (#47672093)

Look, if your target market is highly computer literate than a manual is not a big deal (assuming the program is well written and intuitive).

If your target market is not computer literate, than you either need to offer classes in how to use it, or a good manual.

Web 2.0 (1, Funny)

Jaime2 (824950) | about 2 months ago | (#47672119)

It's much more Web 2.0 to create a user interface that's minimal to the point of being cryptic, and to call users that can't figure it out idiots. It also helps to have a complete lack of standards.

Functional spec (4, Insightful)

mspohr (589790) | about 2 months ago | (#47672133)

Back in the very old days when I had a software company, we wrote detailed functional specs and used these as the basis for the documentation. It's much easier to go from a good functional spec to documentation than start from scratch. It's also a good test of whether or not the software works as intended.
I don't know if people still do that. It seems most software these days either copies some other product exactly or it's just the whim of the programmer.

Every release is a rewrite? (3, Insightful)

BitZtream (692029) | about 2 months ago | (#47672149)

Then you're doing the whole project wrong.

I'm guessing you've got developers with no leadership or plan and certainly no forethought.

You should invest in some project management and developers who are playing for the team rather than just writing what gives them a buzz that day.

No one is going to use your software if every release is so different that you have to rewrite the docs. People use software to get something done, not because they want to spend their time learning how you decided to rewrite it and do things differently.

Re:Every release is a rewrite? (0)

Anonymous Coward | about 2 months ago | (#47672215)

It is likely Agile.

Re:Every release is a rewrite? (1)

anonymous_wombat (532191) | about 2 months ago | (#47672579)

It seems to me that a major problem here is only releasing once a year.

I realize you are not commercial, and that 2 - 3 week release cycles may not be realistic, but you should release no less frequently than once every 3 months.

Also, if there are so many independent pieces, why do they all need to be released at the same time? This sounds like more of a project management issue than a documentation issue.

Re:Every release is a rewrite? (1)

smugfunt (8972) | about 2 months ago | (#47672837)

It seems to me that a major problem here is only releasing once a year.

Odoo is commercial, and Open Source.

As an Odoo user and developer I would be happy with a 'release' every two years or more. I can pull bug fixes from the VCS to keep my current system running.
The 'releases' are for big changes and spiffy new features which require a data 'migration' and code 'porting'. Neither I nor my clients want to be doing that every three months. It is an ERP system not some simple desktop app.

unlike code (0)

Anonymous Coward | about 2 months ago | (#47672155)

Unlike good code, good user interfaces are not self-documenting.

If it does come to cases about raw budget and manpower, get the head of the support department in your corner. Have him bring a couple of his best and or most experienced minions with him too. Regardless of how good the user interface is, they will be bearing the full frustrated weight of clients asking how to do things. For him, every man-dollar spent on the user interface that was taken from the documentation will mean upwards of 10 man-dollars that he will have to spend supporting the clients.

Speaking generally (1)

nine-times (778537) | about 2 months ago | (#47672169)

I'm not aware of Odoo, so I'm only speaking generally, but generally speaking, having a simple/intuitive product does *reduce* the need to documentation. For example, I don't need documentation to tell me that I can open a Word document by going to "File", selecting "Open", and then going to "Computer", "Browse"....

Now, come to think of it, the process for even something as simple as that has gotten needlessly complicated. WTF is Microsoft doing these days?

Back on subject, yeah, if you open files by going to an obvious menu button that says, "Open File...", then I don't think you really need to document that. You only need to document the features that aren't completely blindingly obvious.

The need for documentation can also be reduced by having a good help/support system. If you have a procedure for doing something unusual and complicated that's undocumented, you had better have someone standing by that I can call/chat/email who can help me out. And even still, that stuff should be documented at least well enough that you can train your support staff.

If you don't have good support and something is not completely obvious, then yes, it should be documented.

Build it into the system as part of the process (0)

Anonymous Coward | about 2 months ago | (#47672189)

I currently manage a multiple websites spanning 17,000 pages using a custom written CMS (I wrote) used by hundreds of people. There is no WAY to manage documentation for this that no one would read anyway. Instead I put tool-tips all over the place and have a built in system to manage these as the system changes. Part of the development process is to update these when that section/field changes. It takes me a few seconds to do so and there is no need to create documentation separately.

You could adapt this methodology in your system. In addition allow certain user levels to add their own "enhanced" documentation to the tool-tips.

Here's how my system works. The tool tip pops up in a overlay and I they can edit it. Not only does this allow for crowd source documentation but the ability to add in business logic that defines the process. In fact administrators can update these on-the-fly by clicking "edit". Since I implemented this I've had 0 help requests for how to use the system.

A DevOps/Indie Developer's perspective... (1)

mcolgin (818580) | about 2 months ago | (#47672191)

This is a great topic and immediately grabbed my attention. A lot of it has to do with your resources. As an indie developer for the past decade, I've been working on software products in an DevOps environment as the sole employee. It's tough to keep on top of everything. Development, IMHO, is the most important thing as in a way, it's also your best marketing (a continually updated product shows a vested interest). I've been fortunate in that my software targets technical people (for the most part), but corporate environments can also very old-skool and like PDF and "manuals". To that end, I've started to use wiki-like blog postings to help describe UI elements and program functionality. With Wordpress and like products, it's very easy to put together a quick document with images/text and then link them via a "Help" button in the UI. There's an adage of the "cockpit test", if your software looks like an airplane cockpit, you should look at redesigning the software. There's also "people don't read documentation".. personally, I choose to spend my time in the UI and supplement it with quick documentation. I'm by no means perfect, and I have a stack of things to document via this method; but my hope is that I can stay on top of the UI work and allow that to answer my questions... then again, perhaps I'm old-skool and what I like is perhaps "dated" looking.. I use the hell out of the WinXP graphics pack from Glyfx (https://www.glyfx.com/shop/listings/xp-icon-sets/)

A balance works best (1)

saiena (3785223) | about 2 months ago | (#47672209)

Having written lots of software documentation in the 90s and developed numerous UIs since then, I've come to use a balance of UX and documentation. My strategy is to build into the UI simple instructions for operating each set of controls encountered by the user. Often these instructions appear in info panels that the user can dismiss when they no longer need/want to see them. The documentation then becomes little more than an outline of common and advanced procedures the users may perform within the app with short instructions of where to begin the procedure within the UI. So essentially, the documentation acts as an easily navigable directory of procedures, and the UI provides the step by step documentation within info panels.

plain and simple (1)

pr0fessor (1940368) | about 2 months ago | (#47672219)

Do you know any complex software that succeeded in avoiding documentation by having significantly improved usability?

No. I have worked with software that has tried.... there is nothing more annoying.

 

As a customer, how would you feel with a very simple product (much simpler than the competition but still a bit complex) that has no documentation?

Sometimes simpler is better, but if it's simple enough to not require any documentation then it probably will not meet the users needs.

Re:plain and simple (1)

Obfuscant (592200) | about 2 months ago | (#47672853)

Do you know any complex software that succeeded in avoiding documentation by having significantly improved usability?

No. I have worked with software that has tried.... there is nothing more annoying.

I would even go so far as to define "complex" in the user's context as meaning "requires documentation to use". Users don't care how convoluted your code is, it's complex to them if they need a manual.

I'm concerned about your description of the problem, though. One thousand pages of documentation for four different target audiences and 250 programs. That's one page per program per type of user, on average.

My code is so epic! (1)

ThatsDrDangerToYou (3480047) | about 2 months ago | (#47672221)

My code *is* my documentation!

Sorry, did you want a serious comment? Oh, you want the Serious Comments Division down the hall...

If you need extensive documentation... (0)

Anonymous Coward | about 2 months ago | (#47672223)

If you need extensive documentation... you had failed.

Re:If you need extensive documentation... (2)

ColdWetDog (752185) | about 2 months ago | (#47672661)

If you need extensive documentation... you had failed.

At Kandy Krush perhaps.

At a real program, not so much.

Dear Slashdot... (1)

Lumpy (12016) | about 2 months ago | (#47672251)

Do you think we can get away with being incredibly cheap and not wasting money on writing documentation?

Honestly, write documentation. Only the scummy companies dont.

Let third parties do it... (1)

barfy (256323) | about 2 months ago | (#47672253)

You can coordinate with third parties to create multi-level documentation. This has been done by many well used programs. It improves THEIR ability to provide documentation, creates synergy with others, and lets you focus on development. Spend your time documenting getting to the point of needing further documentation, let others provide it.

If you can't find others to do this, you may be finding that your whole thing may be a waste of time.

Documentation can be opportunity for code review (1)

Dwedit (232252) | about 2 months ago | (#47672255)

If nothing else, making documentation ensures that you get to check that your features are sane and make sense. Nothing like documenting something then realizing how stupidly it was written, then you can fix it so the documentation can be simpler.

User docs, or developer/maintainer docs? (1)

david.emery (127135) | about 2 months ago | (#47672259)

From a user doc perspective, Apple Mac OS X is a great example of what you can do with a minimum of user documentation, but with very mature and fully enforced user interface guidelines. In fairness, someone new to the platform does need some hand-holding, either training (including over-the-shoulder help from a family member :-) or a good book (I'm partial to the Pogue "Missing Manual" series.)

From a developer doc perspective, if you expect to maintain the software, some amount of documentation, that should capture (1) interfaces; (2) design intent; (3) full build/reconstruction directions (including configuration data, etc) is essential. And "Agile" that ignores these documentation/sustainment issues is just an excuse for write-only coding.

Re:User docs, or developer/maintainer docs? (1)

ColdWetDog (752185) | about 2 months ago | (#47672679)

Ack. No.

I like OS X / iOS but I get supremely pissed off at Apple's tendency to 'hide' things so the UI looks 'uncluttered'. Yes, you can run an Internet search on the function, but the thesis here is that you write your own documentation, not have Google do it for you.

Re:User docs, or developer/maintainer docs? (1)

david.emery (127135) | about 2 months ago | (#47672825)

How often do you need to do that? As an "end user" when things work correctly, I'd assert it's infrequently.

But when trying to debug a problem, I agree this is frustrating, and the worst of all is "You are unable to log in at this time. A system error has occurred." and even if you know how to bring up the Console (/Applications/Utilities/Console.app) to look at the error logs, they're not particularly helpful.

So I'll put some words into your mouth and say, "It's important to have documentation available to support troubleshooting or 'power users', but the goal should be that 95% of the time you shouldn't need to RTFM to use the system." Agree?

And access to documentation is separable from existence of documentation. Most of the time, when I'm connected, using a search engine to find this kind of information doesn't bother me. But when disconnected (e.g. sitting on an airplane), not having the information local can be very frustrating.

Bad documentation is very, very expensive (1)

sandbagger (654585) | about 2 months ago | (#47672267)

Being able to articulate your decisions, why and how things are built is a core competence. You will "pay" for poor documentation. It may never show up as a line item, but it can be costly.

It also needs to be someone's job. Depending upon engineers or the sales guys to generate documentation, courseware and manuals is a fast way to jack up your tech support costs.

Some questions are their own answers (1)

taustin (171655) | about 2 months ago | (#47672297)

That you would even ask the question "do we really need documentation" demonstrates that you desperately need documentation. You have no idea how users interact with your software (and all software).

UX? Meh. I have enough experiences in life (5, Insightful)

caseih (160668) | about 2 months ago | (#47672303)

All this talk in recent years about UX as in "experience" drives me up the wall. Talk about euphemism! Why can't we go back to calling it what it is: user interface?

Re:UX? Meh. I have enough experiences in life (1)

Chris Mattern (191822) | about 2 months ago | (#47672965)

Why can't we go back to calling it what it is: user interface?

Because "Are you interfaced? Have you ever been interfaced?" doesn't sound nearly as sexy.

Ask your customers (1)

Dishwasha (125561) | about 2 months ago | (#47672305)

Instrument your documentation pages if they're online. Put high priority focus on the most used pages for your initial roll-out if that makes sense. Have your Product/UX team talk to clients and see if they find the documentation useful and make sure they have a decent quality sample size. Talk to customer support to see if customers are calling in with questions that was available or not available in the documentation. Measure cost to customer benefit and client retention and if you don't know how to constructively do that, don't change how you're doing things until you do.

Community-building instead? (1)

silvermorph (943906) | about 2 months ago | (#47672307)

UX is good, and you have to invest in it no matter what, but it'll never be a silver bullet unless you strip your apps way way way down - something that'll be painful for both you and your established users.

But if your docs really are a bottomless pit, it might behoove you to invest in your community instead of documentation. Grow some in-house experts and put them on the forums and a chat system. Send your users there instead of to increasingly out-of-date help docs and get them in the habit of searching for answers there. Build a reputation for responsiveness to get free customer loyalty on the side. Send your UX people and engineers to the forums as well so they get the pulse of your most frustrated customers. Slowly your community will become your experts as well.

Yes (0)

Anonymous Coward | about 2 months ago | (#47672319)

Should You Invest In Documentation, Or UX?

Yes.

What? (1)

gstoddart (321705) | about 2 months ago | (#47672327)

As a customer, how would you feel with a very simple product (much simpler than the competition but still a bit complex) that has no documentation?

So, I guess first off if your product is open source, do you have customers or do you have users?

Second, say I'm evaluating a new product, and I stumble on yours. After looking around I conclude there is no documentation at all.

Now, do you think I'm going to download and install your software so I can play with it and see if it might possibly be useful for me? Or am I going to look at the absence of documentation as a sign that I should look elsewhere?

My honest answer, is I'm going to assume you're like every other open source project with no documentation and keep looking. Because it smacks of either amateur hour, or the bad old days of open source where all you got for help was "RTFM" (which in this case there wouldn't be), or "figure it out for yourself".

If you've got 250 apps with no documentation, what you have is a sea of unintelligible stuff which nobody is going to want to get anywhere near.

And if this is supposed to be a business suite, how are people going to pitch it to decision makers when you say "um, well, there's no actual documentation". If any business lets their IT folks roll out a project based on software with no documentation, they'd be complete idiots.

If you're not documenting it, people who aren't already users of it will never use it.

And, really, 250 frickin' apps without documentation?? Yeah, no.

Nipples (0)

Anonymous Coward | about 2 months ago | (#47672329)

The only intuitive interface is the nipple and some babies still mess that up. Everything else is learned.

Documentation is necessary. Don't skip it.

Been there, done that (0)

Anonymous Coward | about 2 months ago | (#47672335)

Having written 1000 page tomes of technical documentation for my company's product API's (many of which I wrote) I can relate to your conundrum. These days there are tools that can take embedded documentation from source code and if it is written properly, generate at least a good portion of the documentation needed (JavaDocs, etc). However, this requires some real discipline in the development team to write good (and complete) inline documentation, which is where it really should be sourced from. The development team knows what is intended by the code and API's, and can fill in some other information, such as the rationale behind certain constructs that may not be obvious on the face of it.

In any case, such tools w/ embedded documentation strings can reduce the amount of work to produce a final document product that will be usable by your customers. These can also be put online for web viewing, wikis, etc. In my case, I have always felt that too much inline documentation was far preferable to too little. After all, I may have to go back myself to do enhancements, bug fixes, and such and this helps me recall why I did what I did.

How intuitive is it? (1)

davidwr (791652) | about 2 months ago | (#47672343)

You can skimp on documenting the obvious.

You can delay documenting the obscure, or even leave it undocumented as an "easter egg."

Anything else I would expect to be well-documented OR I would expect the product to say, up front, that its documentation is sparse.

Have you considered making bare-bones documentation in the product and making the full documentation a community-driven project, perhaps a Wiki? Now that the base Wiki software makes it easy to have "pending edits" which are not shown to non-logged-in users, you can do this without as much of a "troll/vandalism" risk as in the past.

Yearly rewrite? (1)

nurb432 (527695) | about 2 months ago | (#47672355)

Sounds like you have bigger problems than your documentation and user interface....

Games. (2)

pla (258480) | about 2 months ago | (#47672421)

Do you know any complex software that succeeded in avoiding documentation by having significantly improved usability?

To answer your direct question: Yes - Games regularly do this, because no one reads the manual (if they even have one).

That said, no one reads any manuals until they get stuck. So realistically, time invested in useability will provide far, far more benefit than time spent on a book that never even gets opened.

However, games have the rare luxury of forcing you to play a tutorial when you start. As much as I wish I could force most of my coworkers to "play" an Excel tutorial every time they start a new spreadsheet, I doubt "serious" users would have the patience to put up with that level of handholding (even when desperately necessary).

UX can only go so far (2)

Dracos (107777) | about 2 months ago | (#47672479)

Just as there is no such thing as absolute security, there is no such thing as a 100% intuitive and self-documenting UX.

No matter how simple or complex software is, there is a limit to how much "help" the UX can offer. The UX should have enough hints/labels/tooltips/etc to keep the user from getting lost performing light to medium tasks, but inline is not the place for describing complex workflows, data structures, APIs, or other heavy topics.

Documentation is the ultimate resource for the users, most documenting elements in the UX should be considered a convenience. The phrase "RTFM" exists for a reason, there is no "RTFUX".

It also sounds like you're handling your docs wrong... they should evolve with the codebase and not need a complete rewrite for every release.

Picasso didn't write documentation (1)

NemoinSpace (1118137) | about 2 months ago | (#47672503)

Although their are plenty of books written by others to explain them. There's an analogy in there somewhere, it's not car analogy, but even automakers let Chilton's write their documentation. So, the answer is no you shouldn't waste your talent on scribe work if you are a genius.
Alternativley, if you need to explain what your program is doing to someone who presumeably bought your program with the expectation that it accomplishes their intended purpose, then maybe you aren't a genius after all.

what documentation? (0)

Anonymous Coward | about 2 months ago | (#47672525)

I thought modern software development is documentation free, which is not to say that documentation is not needed, it is just not done.

You are doing it wrong, obviously (2)

angel'o'sphere (80593) | about 2 months ago | (#47672543)

Make the Apps self explanatory, use mouse overs and build in help. Code so that the developers have to write the code and the build in help same tim, after all the build,in help should come easy from the story/use case descriptions.
Oh, you neither use user stories nor use cases, see headline ...

Perfect UX a myth (1)

Keith Lehman (3785225) | about 2 months ago | (#47672561)

Trying to eliminate documentation would be a mistake, since there are few interesting applications more complicated than tic-tac-toe where one UX would satisfy all (or even nearly all) of your users. Some of us understand visuals more readily than text. Some want advanced features to be readily available while others find it confusing when advanced features are as available as those a novice user would need. How many, and how detailed are your user models? The "ideal" experience is varies from one user to the next. Documentation is one way to satisfy a wider range of users.

Your question also causes me to believe that you can improve your team's overall productivity. Ideally, your UX does not change significantly from one year to the next. If it normally does, you are placing an unnecessary learning curve burden on your users. In that case, you need to improve your understanding of the users, and work hard to create an experience that can scale as the product features and user expertise grows. This is easy to say but not necessarily easy to do. The better your user models, the more likely you are to create a UX that really works.

Another question that comes to mind is whether or not you are making effective use of context sensitive help. Again, depending on the complexity of your application, context sensitive help can play the role of many types of documentation. It can also be easier to reuse. Looking at it this way, effective documentation is a part of the UX, not separate. As such, your documentation needs should only be significant when market and/or the product roadmap justifies it. For example a shift from predominately desktop/laptop users to mobile/tablet users might justify major UX changes.

Hope these thoughts help.

I've used the software (2)

Pop69 (700500) | about 2 months ago | (#47672585)

I've used the software, it was OpenERP in its previous incarnation. I've ploughed my way through the developer and user documentation.

The documentation is abysmal, much of it is not updated between versions and can refer to settings, functions, etc that no longer exist. In some cases I've seen it refer to whole sections that no longer even exist like report design and outlook integration. There are numerous places where it refers to things that do not exist unless a specific module is installed but at not point does the documentation ever mention that the module should be installed.

On the developer side, there appears to be much that is broken by design rather than by error. For what is supposed to be a piece of critical business software, the inability to do something as basic as a bank reconciliation and print off an aged debt report out of the box is unbelievable.

Perhaps working on the core competencies of the software instead of diverging into including web site builder and CMS systems ? Your product can't do something as useful as calculating the cost price of a Bill of Materials assembly, so get the basics working and documented clearly before you do anything else.

At least start documentation wiki (2)

raymorris (2726007) | about 2 months ago | (#47672619)

At very least, start documenting new stuff via a wiki, before new commits get integrated. Better yet, documenting a new feature BEFORE coding it can increase quality and reduce development time by causing developers to think through the user experience before implementing something.

We also have our support and and customer service people copy/paste emailed answers to the documentation wiki so they aren't typing the same thing repeatedly and the information can be found without emailing support in the future. That doesn't require writing any more documentation, just copying and pasting info you're already writing.

Make it work like other software (1)

Pro923 (1447307) | about 2 months ago | (#47672639)

Generally, for a given operating system you try to make your software so that it functions in similar ways to other software. That way, in order to use an app a lot of the fundamental things are trivial. Whenever I've written apps in Windows, for any particular function, I look at how another app accomplished the same task and made mine work like that. A user should be able to perform basic functions of an application without going to the documentation.

New (hopeful) Odoo User (0)

Anonymous Coward | about 2 months ago | (#47672643)

Having discovered Odoo within the past few weeks, I am in the process of wrapping my head around what it can (and cannot) be used to accomplish. I think it might just be the *next big thing*, and of course I am partial to the python+postgres backend, the contemporary bootstrap-integrated frontend, and the sense of an open source community with thousands of users and hundreds of developers. This could all be very disruptive to Microsoft-as-a-platform (tm).

However, I cannot be the only new user who has become drunk on the MARKETING for the latest online-only version ... and then WHAM! Where is the documentation supporting all of these amazing features? As a potential customer (one who cannot use the online version and meet regulatory compliance), I need to reach a conclusion on the true capabilities of this product -- and to know when to cut losses vs push forward to implement specific features. Github is great, but I don't have the time to examine 200k lines of code and templates as a substitute for introductory tutorials, howtos, and general documentation matching the current version. It does not help matters that many of the thousands of available modules appear to be out-of-date, the documentation I have seen for previous versions is scattered among various sites and formats, and the help forum is heavily populated with unanswered questions that might have been avoided with better docs (or better navigation to existing docs?).

So .. I will keep plugging away trying to make sense of it all, and eagerly await the official release of the new version 8.0. I anticipate improved docs will bloom from the community at that time, as well as traditional publishing. To answer the original question: I would prioritize UX over DOCS for the primary development team, but also feature freeze and release on schedule, provide basic (core) documentation, and provide a stable platform for the community-based documentation to take root. And finally, when great documentation is available, please link to it from the marketing page for each amazing feature!

Separate Docs from Training (1)

ripvlan (2609033) | about 2 months ago | (#47672649)

Yes - an obvious UI should reduce the need for documentation. Are you documenting every single screen - and is it really useful?

We split everything into a few buckets:
  * Proper and Intended Use of the product
  * End User Training
  * Suggested workflow and use (kind of a how-to accomplish important tasks)

If users are unable to accomplish their work without reading the documentation - then there is a problem. Our documentation went down from "feet thick" to a small "1 cm thick" manual. Via a removal of duplication and splitting into Role based helped keep changes to a minimum.

Of course - if the UI is changing that drastically every year - are the customers happy? It sounds like there's a huge investment from the customer base to re-learn the product every year. At some point I'd get tired of that and slow down how often I upgraded...or went looking for a less complicated product.

To answer your general question: Yes - it is possible and you will be successful in doing it.
Wider question, not asked but we all derived, it sounds like some change control needs to happen.

Good luck.

Any software requiring documentation is broken. (4, Interesting)

tlambert (566799) | about 2 months ago | (#47672681)

Any software requiring documentation is broken.

I blame Bob Wallace.

Bob Wallace was one of the originators of the concept of "shareware", and he got paid not for his software. This made people wonder how Quicksoft was able to stay in business.

When questioned about this at one convention, he made circling motions with his hands on either side of his head, and said "Software is ... all up here ... it's not real, it's ephemeral. I don't sell software, I sell manuals". So Quicksoft made its money, and its livelihood in the margin between the cost of mass-producing a manual vs. printing it out from a floppy disk and using up a bunch of tractor feed paper and expensive ribbon.

Or, to put it another way, Quicksoft made their money by having a relatively feature-full product which was nearly impossible to use without documentation. And people have been mistakenly trying to copy his success by utilizing the same technique, ever since.

Why did WordPerfect lose out to Microsoft Word? It wasn't because WordPerfect didn't already own the market; it did. It wasn't because Microsoft Word had more features; it didn't. Was Word a lot better, intrinsically, than WordPerfect? It actually wasn't.

Frankly, it was because of the F1 key. By the time WordPerfect got around to deciding they needed a "Help!" key, some of the function keys were already assigned, and so they assigned the next available one to be the "Help!" key. It helped sell a hell of a lot of keyboard templates. And it hid the help from anyone who'd experimentally go looking for it by hitting unlabeled keys in order until they found it (in fact, this would totally screw you up in WordPerfect).

Microsoft hit on a UX innovation: when something goes wrong, make the "Help!" key the first key someone is likely to hit, before all other keys.

And then they did it one better: The F1 was assigned to be the "Help!" key in *all* their products. Instead of just being a great UX thing, locating the key where they did on the basis of probability, they turned it into a Schelling Point: anyone who wanted "Help!" in any Microsoft product knew where to go to find it, if they had ever used some other Microsoft product, and needed "Help!" there.

So back to the original question: should you invest in documentation? Well, yes... if your product has already failed to the point where it's nearly impossible to use without documentation, or because, like Bob Wallace, you intentionally made it nearly impossible to use without documentation because that's one of the premises of your business model.

Maybe you want to write books on your project, once it's used by enough people to make that profitable, and that's how you plan to turn your hobby into a vacation fund. Or maybe you want to get to be a published author about a product so you get hired as a tech writer somewhere, or you get a lot of speaking engagements, and monetize your efforts that way. But if making your product hard to use was one of your initial conditions, then I think your software is broken.

How about: (1)

drolli (522659) | about 2 months ago | (#47672703)

Both?

Hmm... Windows? (0)

Anonymous Coward | about 2 months ago | (#47672709)

Windows has always been a complex piece of software that shipped with virtually no documentation.
It seems to have done quite well despite.

Why wait until the very end. (1)

blueshift_1 (3692407) | about 2 months ago | (#47672771)

Project work isn't just about coding. You shouldn't wait until you're entirely done with a big piece of the project to adjust all the documentation. Like anything, it should be done in increments. People can't effectively use an application with proper documentation nor can they use a well documented piece of junk software. When developing, you have to weigh the cost of each of these and try to do them at least reasonably well. But you can't just have one, nope nope nope.

Literate Programming (0)

Anonymous Coward | about 2 months ago | (#47672995)

This isn't done all that much but systems like Knuth's cweb might come in handy here?

Possibly of limited use in user documentation but could lighten the load for the
developers documentation, especially if it's a small core of developers.
Might need to involve an editor though.

Send your source through one filter and out comes a program,
through the other, the typeset documentation. The source includes both code
and the relevant documentation is near the actual code.

 

no (2)

Charliemopps (1157495) | about 2 months ago | (#47673003)

I support a lot of apps... some with lots of documentation, some without.

If management came to me an asked me to assure them that your application was secure enough to store sensitive data in it, and you had no documentation... how could I assure them of that? Does the application calculate financial data accurately? I don't know. What's the developers long term goals for the product? Does it support X format? How far along is the API? Are they getting rid of it?

Documentation is far more important than just "How do I save a file?" Without it, most businesses will never approve your product for use because they'll not be able to get answers to whatever questions they need answers for to approve it.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?