As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm not a usability specialist, and I really don't care to be one.
I just want a small set of rules of thumb that I can follow while coding my user interfaces so that my product has decent usability.
At first I thought that this question would be easy to answer "Use your common sense", but if it's so common among us developers we wouldn't, as a group, have a reputation for our horrible interfaces.
Any suggestions?
Source: http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png
Read Don't Make Me Think by Steve Krug. It is a great starting point, and an easy short read.
EDIT: This is mainly for web usability though, but it would still be a good read even if you are doing rich clients.
Just two things, really:
"A user interface is well-designed when the program behaves exactly how the user thought it would" - quoted from Joel Spolsky's User Interface Design For Programmers
Put your designs in front of a user. A real end-user is best, but for lightweight, rapid feedback, you can't beat hallway usability testing i.e. grab a co-worker.
If you remember Joel's advice and make sure you get feedback on whatever you do and act on it i.e. iterate, you'll not go too far wrong. And I would echo the recommendation for Steve Krug's Don't Make Me Think - it's probably the best work-related book I've read, bar none, and is just as applicable to desktop software as websites.
Hope this helps.
Don't make things work in a different way than your users are expecting (i.e. breaking the "back" button when using Ajax in web forms
Follow the K.I.S.S principal
Really, any rules someone posts will be a variation on the theme:
Don't Make Your Users Think
"Don't Make Me Think" has already been posted, see also
Design of Everyday Things and Designing with Web Standards which are also great for light usability reading.
Avoid modes. It's frustrating to a user when input works sometimes but not others, or does different things at different times.
The single most important piece of advice I'd give someone is to work on the UI first. Pen and paper and all. That way, you won't subconsciously couple buttons to functions, input fields to variables, etc.
The best UI might be a pain to code, and if your backend code is mostly written, it will sabotage your thinking.
Other than that, I'd point to Apple's Human Interface Guidelines. Of course, if your platform is not OS X, take the OS X sections with a lot of salt. What works in OS X might not work on Windows. You should embrace your platform's idioms.
OS X stuff aside, that document has some pretty good starting points on the fundamentals.
Here are some simple rules:
Fewer clicks are better.
Frequently used features should be easier to find.
Features for "advanced" users can be harder to find than the ones above.
Think about the number of mouse/keyboard clicks it takes a user to get to something.
PS - please don't tell the Microsoft Office 2008 people about this; the poor little guys would cry themselves to sleep tonight! :)
Think about the users that will use your app. Why are they using it and in which context?
Will the majority be pro users that know the domain in which the application is used and use the app a lot? Then don't be afraid of adding a lot of data to the screens as long as it arranged logically for users (normally that is not in alphabetical order :-). Think trade screens for stock borkers or airplane cockpits.
Are users occassional users? Keep it simple. Avoid context switches (keep all/as much as possible of necessary data for a task on the screen at each time). Don't break expectations of how gui widgets normally work. Design for failures.
Anything in between? Allow users to grow in the UI. Track usage so you can later determine where users seem to spend the most time so you can improve the most used areas of your app.
Test your app on friends and colleagues (the corridor test) to see if they are able to use it efficiently.
That's a start.
I suggest to read these blog posts from the Enso creators.
Of course they repeat guides/ideas/advices from books such as
The Design of Everyday Things and About Face, but nevertheless, the posts contain quite a few insights and (IMO) they are a good read.
What information does your user need, put that on the screen and nothing else. If you cannot define what the user needs - get another user.
Remember that your application will be one of many the user will have to deal with. Don't do things just to be different or kewl. Don't come up with unusual graphics, behaviors, terminology, or interactions. Use the standard OS controls, conventions, utilities, and behaviors.
Let your app interoperate with other apps; allow cutting and pasting of data, save your data in formats other apps can read, and allow importing data from other apps instead of using your UI.
If you are making a desktop app, do not try to take over the user's computer. Leave the user's Documents folder, task bar, and application preferences alone. Don't change anything already installed on the computer. Allow scripted or command-line interactions.
If you're making a web app, do not try to take over the browser. Do not try to subvert the standard menu bars, history, layout, or fonts. Allow the user to change the page using Javascript.
(1) Common actions should require as little effort as possible and should be obvious; on the other hand, actions that are rarely needed can be require a lot of steps and can be hidden behind menus and dialogs. To be able to do so, you should always describe what the user will want to do with the application by listing use cases.
(2) A UI should be selfdocumenting. The manual should be integrated in the application's dialogs and menu's, as users don't read separate manuals. For example, the keyboard shortcut should be shown in the menu item representing the action it is associated with.
Provide keyboard shortcuts for power users (even if it is as simple as "hit enter to search")
Don't put too much on screen at once.
If you pop up a messagebox, your users generally won't ever read it.
In addition to the other recommendations here, I'd recommend Designing Interfaces by Jenifer Tidwell as a good way of becoming familiar with UI conventions.
Also, The inmates are running the asylum By Alan Cooper is excellent for providing an insight into how to approach interaction design.
A good follow on to Don't Make Me Think is Robert Hoekman's Designing the Obvious. It's more focused on web applications, as opposed to web sites like in Krug's.
Simple is better than complex
Complex is better than complicated (eliminate 'nested ifs')
Intuitive (good elements needs no explanation)
Follow the convention (for example, underlined means link, red means error, tab goes to next field, etc.)
Use semantics to apply the logic (header reads first, paragraphs next)
whitespace is important
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I have a program I wrote and I have been encouraged by folks to release it into public.
What would be the best way to go about it? Just dump it on a public site and hope for the best?
How much criticism will come (on the standards, decisions made etc...) and how best to prepare for that. I have been the sole developer for this app for about two years.
And how much difference does the license (GPL, MIT etc...) practically make?
Any experiences?
A license is a good idea, even if you don't care what people do with the code - most of the time people will happily take code "as is" and if it doesn't do what they want they will just throw it away - but you never know when some idiot might try to sue you because they burned their mouth drinking a hot coffee while reading your code. You may also wish to restrict usage (derivative works etc) where someone else makes profit out of your hard work. Fron the other side of the fence, people who might take and use your product/code like to know where they stand with regard to use/copying/distribution. By asking that your name stays on the code, you can also ensure that you get vcredit for the work, and that any improvements/suggestions that happen in the wild can make their way back to you.
If you just want to give away the code wihtout much ongoing development, then a great place is CodeProject - you can release the application and write a small article describing it, and then it's up to you to decide if/when you will post updates.
If you want other people to collaborate then there are plenty of open-source websites that will support this approach.
As for criticism, you are likely to get a few mails from people who need tech support, or who want to suggest extra features. Most people are very polite though. If you wrote the program for yourself, there is a good chance that when it gets into the wild you will discover all the bits that have to be used in a particular way to work well, and all the additional options that you don't care about but which the product needs to make it applicable to a wider audience - you can get sucked into a lot of support work if you're not careful. Ultimately don't be afraid to say "no" to someone if they ask for something you don't want to support - it's your program and your time after all.
The main thing is to have fun :-)
Using a well-known, well-tested open-source license will make it easier for your users to know where they stand with regard to your code. The worst thing you can do is release your code without a license. No license means no use, since in most jurisdictions software is automatically copyrighted with no right of use or reuse.
If you don't want the project to wither away from lack of interest, you'll need to get it in front of developers. Releasing it at a large open source project site (such as SourceForge, GitHub, or Google Code) will help you get that visibility, and will provide a lot of infrastructure for managing your project. The more you do, the better the chances that others will find it, try it, and use it.
CodeProject is a good suggestion- but it really depends on the platform. Typically users of each major development platform flock to other sites for their Open Source extensions or apps. For example, lots of developers on the Microsoft stack look for things in the Visual Studio Gallery or on CodePlex. SourgeForge obviously has its own religious following as well. I would suggest promoting your new app on a site where you would go to find something like it. The Google page rank of whatever public site you use to host it will also impact how many people find it and ultimately how much criticism (constructive or otherwise) you get on the project. Licensing is always a good plan. It has been my experience that each major open source collaboration site tends to learn towards a specific licensing mechanism, so I would just do what seems to be the most popular if you don't have any specific requirements.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Is there a reason not to use wordpress and develop your own blogging system?
Same goes with Durpal and our own CMS.
I am wondering since my marketing women disagrees with me that we should develop our own in house solutions because there are better solutions. She also says that we might even loose time and money on it since it is our responsibility to maintain it and solve bugs and we can't throw it on wordpress' dev team for example.
I don't want to invest time in something that might not worth it but I would really like to make more money.
Does it depend on the site's scale and visitors?
What are the factors of choosing one over anohter?
There's rarely a right answer to this fight. It's a question that has raged on since software was sold "off the shelf". Many pros are also cons.
Pro 3rd-party:
They cover a vast number of features
They (hopefully) look after security
Open source means other people can fix your platform.
You get improvements without having to work on your own platform
They have existed a lot longer than your newly conceived project. A lot bugs have been driven out.
Anti 3rd-party:
They don't have all the answers for every project
By extension, it may take you longer to hack in what you need than it would take to just start afresh
Unless you're using it exactly as intended, performance isn't going to be as good as it could be with a custom-built
Larger target for hackers and script kiddies
As they're older, they can be locked (via legacy support) into some bad habits (Drupal and Wordpress certainly have enough)
So if you're doing a blog, unless there are features or platform issues, I'd seriously consider WordPress. If you only needed a very simple blog attached to a much larger system that was completely non-blog, I'd probably write my own as part of that system.
Just to blur the lines, the modern frameworks (Cake, Symphony, Django, Ruby, etc) handle lots of the security, database, usability and let you develop the application without having to worry too much about anything. You get exactly what you want and you get it fast but it probably won't be as polished (eg for blogging) as WordPress.
Good question, +1 :)
My Opinion:
Whatever the scenario, if there is a solution out there that meets your needs, it's open source and your team as the knowledge to make any specific change it might need to meet your purpose, it is probably a good choice to use it. It will save you time(time is money) that you could use to other tasks.
From a developer perspective, it is way more appealing to create something from scratch.
You just have to keep in mind that this is not something you are doing as hobbie, you need to have a product out there as fast as possible, with as few errors as possible, with all the features that the users would expect.
Really it comes down to this:
How much time/money would it require to roll your own?
Does the open source solution you're considering have the features you need (and do they work*)?
How would maintenance of the two solutions compare?
Some "common" answers:
A lot, particularly if you need (or want) a lot of features.
Most of the mature systems have some kind of plugin system and heaps of functionality. Generally if you want it they got it, perhaps some minor tweaks would be necessary.
In-house code may need some time to mature, after this they will probably be about the same. If in-house code is low on features then it may be easier to maintain.
She also says that we might even loose time and money on it since it is our responsibility to maintain it and solve bugs
How is that worse than an in-house solution exactly?
This really depends on your business model.
If you are selling services using an existing open source product can make a lot of sense. (And by the way, you probably can get the wordpress people to work for you - you'll have to pay of course, but you also have to pay your in-house team)
If this blogging system is only for your own usage it makes even more sense to use an existing solution, and the open source solutions stand out in that area because there are a lot of people available that could code some custom solutions for you.
Only if you are actually selling the software the situation with open source becomes a bit harder to get a grip on money-wise.
Our host Joel Spolsky has written an interesting article on this subject.
Yes, there are a lot of reasons. Being open-source doesn't mean it'll automatically be well written.
However, sometimes it really fits your business model because you need to ship something fast, usable, not too specific in requirements and already tested by millions of people. In this case, doesn't make sense to produce something in house.
If you want to convince her of using Wordpress instead of building one, show the arguments on time and money that would be spent in trying to write from scratch instead of using an open source solution. Don't forget to show some live examples from big companies that are using Wordpress (check the official website).
For most companies, developing your own blogging solution is the equivalent of developing your own version of the machine that mixes the tarmac to make the road that leads to your office.
The only exception is if you want to get into the road-building business. But that's a hard and competitive business, an established stable market with a lot of capital requirements, not something to wander into.
I'm working on a product which is meant to be simple to use and simple to set up, the competition largely requiring a long set up period and in some cases going as far as a bespoke solution for each customer. One part of our application is now expanding based on customer requests and it is looking like we'll need to make it very flexible so each customer can have a lot of control over how it behaves for them. The problem being that I don't want to make the system too configurable, as I believe this then makes it more complex to learn and to work with. I'm also concerned it opens the door to someone messing things up for themselves, kind of like handing them a gun, although I'm not actually pointing it at their foot for them.
Has anyone else faced a similar dilemma of putting power in users hands? How did you solve it? and what was the result?
I don't normally like to subscribe to the idea that all users are stupid, but there is a rule which can still be applied:
If you give them the opportunity, they WILL break it
Now it is up to you whether or not to give them the ability to do potentially dumb things. Or better yet, develop it so that when they do do the stupid voodoo that they do, it can be reverted or recovered from error state gracefully.
I highly recommend you read Joel's Controlling Your Environment Makes You Happy, which can be described as a treatise on user interface design but is really about usability with a healthy dab of psychology thrown in.
The section I'm referring to is Choices:
Every time you provide an option,
you're asking the user to make a
decision.
This is something I strongly agree with. Many developers, product managers and so on take the easy route and instead of figuring out what users actually need, they just give them a choice. You see this in enterprise bloatware like Clearcase or PVCS where there are so many options--90% of which you'd never change--indicating the designers have tried to make it all things to all men rather than doing one or two things exceptionally well.
Instead it just does lots of things badly.
Keep it simple, follow conventions, don't overwhelm the user with pointless and unnecessary choices and make the software behave like a normal user would expect. That alone would set you apart from an awful lot of other products.
Personally I like the TurboTax model (http://turbotax.intuit.com/). When creating a tax return, I get a simple, tell-me-like-I'm-five wizard that takes me step-by-step through the process, but I can step outside the process at any time and use more advanced features, returning to the process later.
Make it easy and simple and uncluttered for your user to do what they're going to do 80% of the time, but give them the power to deliberately step outside of the norm.
Interesting timing for your question. In the U.S. this is Income Tax week. Filling out the ol' 1040 and associated subforms should give us some sympathy for what users endure.
Lessons I take away are:
Only ask questions that relate to the user domain; avoid questions relating to the software system; and if you can derive the answer or suggest a most likely answer, do so.
Put related questions together (as long as they are normally entered by the same person using data most likely available at the same place and time, which is the definition of related for these purposes).
Make it support incremental input. It should be easy to enter the data they have, and defer completing it when the rest is available.
Show status validity and completeness. Make it clear and obvious how far they are to having validatable data.
Make it interruptable. Make sure it's possible to interrupt the process, leave the application, come back, and resume where they left off.
Yup, it's harder to program. Embrace it.
There are at least two ways to build a good software product:
Focus on a narrow set of functionality, and implement that functionality very well.
Design your system to be customizable (ideally, through scripting.) If you do the base system right, it will be easy to provide the basic, no options, just-do-what-I-want functionality on top of the customization layer.
Unfortunately, there are many more ways to create a bad software product.
Your questions implies that you can either provide a flexible solution OR make it foolproof.
I wouldn't put it like that. To me this is rather a matter of user expectations and the question in the first place would be:
How can I meet all important user expectations (even if they conflict with each other) without corrupting the application?
For instance a web application which has a menu, breadcrumb navigation, a site map and a search offers together with the inline links five different ways to find what you're looking for and how to go there.
That way most users can find fast and easily the functionality they are expecting and therefore the need for an extensive documentation might actually decrease.
So the answer might be to offer several different carefully chosen ways to solve one specific task, while each of them can be streamlined independent to avoid user mistakes.
The answer with this lies in who your end-users are. I used to write software that got used by professional sports coaches. While these guys were definitely good at what they did, they were hardly proficient at computer use, so our configurability was kept to a minimum (at least as far as what could be done in the GUI).
On the other hand, if you're dealing with power users, adding options is usually not a bad thing as long as they aren't intrusive.
It's all about who's going to be getting them.
Read Jeff Atwood's Training Your Users. It's a great article with some very useful links.
I like the approach of Firefox towards this. The basic options are accessible in the option menu, all the rest is under about:config. Thus you have an easy interface and an incredible flexibility if you need it.
I've had great success, and been happiest as an user, when using sensible defaults. In other words, make the most common use case easy (or even better, free), but give users the ability to step outside of that use case when the situation calls for it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I am writing a system requirements document and need to include non-functional requirements relating to the usability of the system, but am not sure of the best way to express this.
"The system shall be easy to use" seems a bit vague to me, and not testable. Are there any 'official' standards/guidelines that can be adhered to relating to the usability of a program?
Usually, we try to hash out an application-specific definition of 'easy to use'. For example, for our current project, easy to use means:
-All delays in the system longer than .5 seconds will produce a dialog box that says "Please wait."
-It is possible to reach any given system function from the main window in less than 3 clicks.
-It is possible to accomplish any given task with just the keyboard, without the mouse.
-All buttons in the system will adhere to established button convention (link to established button convention regarding size, naming, position, etc.)
-All screens will have a help button. Each help button on a given screen must provide at least one 'topic' for each control on the screen.
-etc.
These sorts of things are testable, and taken together, constitute a 'pretty good' usability standard. That said, nothing substitutes for actual users trying it out.
Usability requirements are hard because the only way to know if your system is usable is by having real users try it out. How will you know if your requirements have been met? To do that, you need formal metrics for usability. Those metrics have to somehow be extracted from the results of usability testing, and if you abstract your usability testing to the point where you're just getting metrics out, you're missing out on its usefulness.
Some items like "must be able to do X with Y many clicks" or "system must respond in Z milliseconds or less" are useful, but they're actually functional requirements that have to do with usability, not usability requirements in themselves. It's quite possible (if not likely) that you can design and implement a system that meets all such formal requirements and is still frustrating for the users. Again, the only way to know is through usability testing.
Well, 'The system shall be easy to use' is exactly the kind of documentation that frustrates both designers and developers, so let's see if we can do a little better than that shall we? :)
To start with, you may find it helpful to sit down and imagine exactly who the intended user is. Give them a background, give them a bit of colour, then send them to your imagined application and try and figure out how they as individuals would want to interact with it.
Remember, different users are concerned about different aspects of usability. Don't just concentrate on the story path you think you would follow if you were using the application.
Next it might be helpful to break the site down into usability components. Does it have a lot of pictures? If so, what's the best way of presenting a lot of pictures to a user. Does it have a deeply nested menu structure? Might there be a better way than a sitetree to help your users navigate their way around?
Usability design patters will help you here. A good resource for design patterns for usability can be found here and here. Design patterns are good because they clearly explain to everyone involved how certain functionality is supposed to work.
Take a moment to consider accessibility in combination with usability. How the site work with javascript turned off is always a very good place to start and can be a great help to developers who tend to get very tired of watching their designer stick yet another <a> link on a page that is going to need to submit a form.
Remember, usability is about clarity and it begins with clear communication to the people building the system. If you can't speak clearly about what you want built how do you expect the developers to build something functional? Take the extra time to paper prototype if you have to.
My reply may be a little too 'web' focused to be of enormous use to you, but I hope it provides a few useful tidbits amongst my ranting.
Metrics & Usecases.
We have a number of personas that encapsulate our different customer types.
We have the user poweruser (George, he's a nerdy, university type),the non-tech person (Frank, who can barely use a calculator) and someone in between (Susie, she knows how to surf the web and can talk to tech support but don't ask her what emacs is).
Based on that we say:
For feature X, George should be able to access it without using the help or pausing longer than a few seconds, Suzie may need to look at the help but probably won't and if Frank does it better be real clear because he doesn't have much patience.
Now, for metrics, we also have usability study guidelines, like out of 10 people, 8 should be able to access Feature Y without looking at the help or be able to do it with 30 seconds.
Those are really subjective, but it might help you get going to in the right direction. Plus, it may help you talk to non-developer types who "just want it to work and be easy".
It wouldn't hurt to read Joel on Software articles too.
The most unambiguous way to include usability requirements in a requirements document that I could find is: make lots of screen mock-ups (and connect them with the "flow" of the performed actions, e.g. by having an arrow point from one item at image1 to the relevant next item on image2 etc.). If people actually see how something is supposed to work, it's easier to understand and leaves less room for interpretation.
Here's GNOME's documentation regarding human interfacing. This is intended as an example of how to specify, not what to specify (as I don't agree with everything they're saying in there).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
A (non-technical) friend of mine has asked me how to make a website. I get this question all the time. After a few questions I found out that she has an idea that could turn into a commercial site. I described three options to her:
a) Get a book/enroll in a class/follow some online tutorials and learn how to do it. She's pretty smart and her personality seems like a good match for this sort of thing so I'm sure she could learn but she doesn't have a lot of time spare. Maybe if she started with one of those WYSIWYG editors at first? I stressed that this would take a longer than a couple of weekends of playing around.
b) Hire someone to build it. Ranges from ultra cheap to ultra expensive, crappy to good and everything in between. I didn't mention sites like Rentacoder because she hasn't worked on a project like this before and doesn't know what to ask for. At this stage she'd likely ask for a Youtube-MySpace-Google for a few hundred bucks because she doesn't yet understand just how much is involved.
c) Find someone technical and partner up with them. I explained that this can either work really well or be a disaster because she'd have to give up some of her ownership of the idea.
How do you respond in these situations?
Depending on the nature of the required website (ie whether she needs shopping carts etc) I often recommend first creating a blog, although it's often not the best format, it can be used to quite good effect at times. I've seen a number of small retailers for example, using a blog to advertise their wares.
It depends on the person and their motivation. Your friend sounds like she should take option b) or c). She's probably not so much interested in the technical aspects of making a web site as she is in seeing her idea come to life, or maybe running her own company based on the idea.
Well in general there are several steps:
Determine the subject of the website.
Determine the target audience.
Decide on a general layout and look and feel.
Decide which techniques to use.
Design the overall structure of the site.
Collect content and images.
Implement the site.
Most of the times, these steps are carried out by more than a single person. Because they all require their own specialization.
I think that the only realistic options are B and C. Non-techies will almost never come to grips with real web site development. With all due respect to those who have advocated technologies such as ASP.NET or PHP - it won't work. In fact, you are likely to be fielding questions for weeks on end as to why things don't work. You'll have to bear these questions until the person, having failed, gives up.
If they have the resources, then I would strongly recommend the "hire an expert" route.
In either realistic case, they must get a legal agreement in place. If she does hire an expert, be sure that the agreement expressly stipulates that this is a "work for hire". If your friend doesn't demand a work-for-hire clause then she will have no legal means to stop the developer from using the exact same code she just paid for in creating a competing site (at least in the U.S.). Just to emphasize: they would have no legal means to prevent the developer from starting their own competing site without a work-for-hire clause - the courts won't even hear the suit.
Now, if it is really just a brochure site or something similar, and they still want your advice, then it depends on whether they use a Mac or something else.
If they are a Mac user, I tell them to try booting up iWeb and using it to feed a .me account. Just plug in some pictures and some text, upload to your .me account and you are done.
If they are a Windows user, I direct them to Register.com or a similar online Web Site template-based site builder.
For your sake, don't volunteer to help unless you are really sure you have the time to essentially build the whole thing for them! You can ruin friendships this way: friends and family, having no clue what really goes into the construction of a site, almost invariably assume that it is "trivial" for you. If you delay or fail to get things done quickly enough, they'll almost always assume that you are blowing them off and they'll resent you for it (can you tell I've been there?).
It depends on how confident she is that this thing will succeed or, alternatively, how unwilling she is to share ownership. I'd definitely not recommend (a) for something that has commercial value. Beyond the time-to-market factor, initial impressions are something that is very hard to overcome. If she has the cash and is possessive of ownership, then (b) could work well. It's a bigger financial risk, though.
I'd probably go with (c), but then again I'm on the other side of the equation. There are lots of ways of structuring a partnership that would help her maintain ownership, though probably not complete ownership since no one wants to work for nothing. Some combination of b/c is probably best - some less pay in exchange for a small stake in the business. I'd definitely see a lawyer before doing (c) and maybe even before doing (b) just to make sure any agreement she has with the developer precludes them taking the code and running.
There are really two questions here: should she learn how to write a website and, if so, how.
If she has a commercial idea and she only wants to learn how to write websites to market it, I would suggest that she does not bother. Outsource instead.
If you have someone who to trust then only 3rd option is realistic. first one takes years to give out good result and with second one you never know what you get.
Buy her a book for her birthday on ASP.NET or PHP.
A bit of topic but here it goes...
We have ONE web designer at our company(we are about 10 programmers), we usually make some jokes like: "You do not work, you just sit there making drawings all day long" (just for the record, she is very competent and does her job pretty well).
So one time she stares at my monitor for about 2 minutes while i am working on a web application, and at some point she says: "Sooo that's what you do? Formulas and stuff?".
From that day on we all say "I do formulas and Stuff" when asked for what we do at work, as for most people, saying that and saying you develop web applications is the exact same thing.
Developing a web site is not as trivial as places like GeoCities or Google Pages would make it appear.
Here is a list of things you need to know about or consider when publishing a site.
If she owns a Mac or doesn't mind to acquire one, I would suggest her to have a look at iWeb. Otherwise, starting a blog on a platform such as blogger would be a nice first step for a non-technical person.
I always give the same answer, HTML. I say what it does and then tell them to get a book. If they get what it is about they will follow their own course of action.
Unless you're a web designer, 'how do I make a website' is a similar question to 'how do I make a television'. You don't, you buy one. So this question is probably 'How do I procure a website?'.
This breaks down into:
Working out what you want:
What user features do you want
What do you want the UI to look like?
What admin features do you need?
Do you already have a graphic design/logo/color scheme, etc.
Finding someone to make it for you
How do you find them? Referrals? Local web dev companys? Friends?
Do you care which technology they use?
Are you going to project manage it?
How do you know they're doing a good job?
Are you clear on issues like scaling, support, maintenance?
Ideally, find a single company who is comfortable helping you work through all the issues. Less ideally but also good, find a consultant or company that will help you with the top level stuff and assist with production of technical specs that you can then take to a development company to produce.
(Edited for formatting)