11 More Detail

We will be writing more detail in following articles, but more detail is immediately available at http://www.guibot.com/ as well as in Dr. Dobbs February 2005 issue under our article “Extend UML”

posted at 12:19 pm on January 25, 2005 by Tim Meehan

12 Lot of words about things that everybody knows

This is just a very global view on what and how to do in a development process. In fact information architecture has become an important part of web development process a long time ago and it has enormous amount of methods and approaches which were not mentioned here.

posted at 01:22 pm on January 25, 2005 by Elinity

13 This is not at all what I think of when someone sa

However useful or helpful this methodology may be, it’s worth pointing that this is generally not at all what your clients or coworkers will be expecting when you are asked to deliver a “use case.”

What is described here could be considered a “business use case,” but it seems more like a user scenario to me. True use cases, by contrast, specify the goal in context, preconditions for success, success and failure end conditions, primary actor, and relevant triggers (if any), and proceed by stepped actions (including branching actions) from task inception through completion. This, at minimum, is the information your deliverable will be expected to convey.

posted at 02:10 pm on January 25, 2005 by adam greenfield

14 The global aproach was left aside

Norm and Tim began their article with pointing to the most difficult questions, which still are undecided for many projects in development. They are: “What problem are we solving? Who needs it? What’s this site for, anyway?” (These questions are just a quotation from the article and later I’ll restate them.) But later in the article they put these questions aside leaving the global level and descending to more practical level of the work on the project.
And I think that before using some practices like use-case we must concentrate on the global planning and answer to 3 main questions:

1. What are we designing the site for? What are the goals that will be archived by this site?
2. For whom are we designing the site? What are the goals, needs and demands of potential users?
3. What information can we deliver by the site both to archive the goals of the site’s owner and to satisfy the users?

I think these are three pillars of any web-site development project. And they are exactly those main questions about which Norm and Tim just mention at the beginning of their article and then go over to practice, to use-cases.
But without clear understanding of what we want, who our users are (what they want) and what we can give to them by means of our site, we won’t be able simply to say WHAT WE HAVE TO DO, we won’t know how we should work and what we should get as a result of our work.

And later, after answering to these questions, as an evolution of the answer to the second question we finally can get back to use-cases described in the article.

posted at 12:54 am on January 26, 2005 by alex-and-r

15 Choice of cases

I liked the article but I did think that the choice of case was a little confusing I’d have had blog in the centre rather than publish blog then labelled the right line publish and possibly also given them an administor link as well and then given a visitor comment and also read.

Overall a good introduction with a lot of scope for a follow up.

posted at 01:58 am on January 26, 2005 by Adam Bardsley

16 bullshit

i call bullshit. software engineers don’t know much about design, the actually fuck up most of the projects designwise. look at how bad most software is. and the best part is that most software development happens outside the “established” software engineering theory, because this theory again adds nothing to the process, but it actually kills good design.

do you really want everything to be as unusable and unstable as software is? if you want to look at examples, look at architects, look at product designers, look at other design disciplines where at least some portion of the products are decent. forget software engineering as a role model, it can’t teach you nothing.

posted at 08:10 am on January 26, 2005 by peter

17 hmmm

“forget software engineering as a role model, it can’t teach you nothing.”

What an enlightened approach tho the pursuit of knowledge and understanding.

I’ve found use cases very helpful in developing websites with a lot of back-end functionality, i.e. web applications (which, like it or not Peter, are pieces of software). Use cases are just a tool that can be utilised, just becaue you use them doesn’t mean your site will be an outstanding example of good design, and vice-versa.

Architects have been around for thousands of years and you still get crap buildings. Software engineering is still very much an evolving discipline and to say that people who build websites can learn nothing from it seems a bit, well, dumb.

posted at 09:31 am on January 26, 2005 by Tom

18 Use Cases vs. Use Case Model

Excellent! I think there’s much to learn from Use Cases.

However, forgive me if I’m wrong, but I believe that what this article describes is more the Use Case model than the Use Case per se.

The use case model is a visual representation of all the use cases: the stick figures, the arrows and the bubbles. Each buble in this diagram is a use case.

A use case is usually documented in writen form (paragraphs and bullets), and describes the actions taken in that bubble. That is, the user inputs/actions and the system responses. These could potentially “link” over to other use cases (sort of like a sub-routine in programming).

My preference is to have both, the Use Case Model and the acompanying Use Cases. That way you can look at the diagram to get the big picture while reading each use case (the bubble stuff) for the details.

All in all, a good teaser…

posted at 12:55 pm on January 26, 2005 by Andres

19 Use Case Stencil for OmniGraffle

Regardless of what title seems fitting, creating a visual for clients can be extremely valuable to communication.

For those of you out there with OmniGraffle, I’ve put together a rather simple stencil to create use case diagrams.

http://www.mediaville.net/projects/stencils/

Hope it’s useful.

posted at 03:16 pm on January 26, 2005 by Stephen Yoch

20 Use Case with Caution

I have to agree with Adam Greenfield that the examples demonstrated here are not a good representation of ‘real world’ use cases.

As a programmer who has endeavoured to work closely and thoughtfully with interface designers, I’m quite aware that a improperly rendered drawing – however simple – can confuse and muddle a conceptual understanding of a simple functional model.

For example, the first illustration in the Carr and Meehan article might suggest that both the Visitor and the Author can publish the weblog. Is this the case? Of course it’s not, because both arrows point towards ‘Publish weblog’ this could suggests interaction by both actors, this is where confusion can arise.

I am lucky enough to have colleagues who are developing code using agile methodoligies. Exposure to these guys is providing me with some techniques and learnings to experiment with during project definition and scoping with designers and client managers. In particular user stories, sometimes combined with use case illustrations can be very effective.

Unfortunately, it seems that Peter above, is of the opinion that software developers know little about design. Artistic and graphic design maybe, but if you’re to suggest that they know little about application design – well, you’re wrong. There is a language for every field of knowledge and to communicate with individuals from other fields you must learn their language. Bearing this in mind can improve how effectively you can work with software developers – and how software developers and work with designers.

posted at 06:11 pm on January 26, 2005 by Travis Winters