Re: Modelling and communicating dynamic Web functionality

Hi Conrad

I receive the type of briefs you are helping to write. I have also  
helped clients write the brief for us, as a way of taking their vague  
concepts and notions and turning it into something we can design and  
build against.

My instant reaction? That the problem you are describing is not a  
problem at all, and not something you should worry about.

The brief for a website such as this should, in my opinion, describe  
the page/screen interaction. That is after all what the end user will  
see when they use the site. The end user won't know what databases  
tables are being queried when they click a button, and why should they.

The brief to the designer/developer should describe the interactions  
required by the user of the website. For example; Clicking edit my  
events should take the user to an edit event screen where they can  
amend x, y and z details. It should not be concerned with how that  
data is structured.

The reason why you don't need to specify is because the web developer  
will deal with it. If a site is to be CMS based then the developer  
will know what CMS they will want to use from reading the brief. This  
may be their 'base' CMS (the one they use for every project because  
they know it inside out), or they may pick one 'off the shelf' to suit  
the exact requirements of the project. Rolling a custom system from  
scratch is very rare these days, due to budget, time and there is just  
no need as their is a very mature CMS market out there.

The CMS will decide the database set-up, fields and interactions. The  
UI is layered on to top (with some code logic) to perform the tasks  
the user is required to do by the brief.

I would suggest that if your brief stated how the database should be  
structured, it has more chance of putting off web developers than  
attracting them. Not because they are annoyed that someone is telling  
them how to do their job. Instead because they might find it difficult  
to quote when they know their CMS does not match the database spec --  
but it will perform and deliver the end result just fine.

You would be much better off spending the time honing and refining the  
user flow, and interaction points, than worrying how the underlying  
data is being structured.

Just my 2p

Matt




On 19 Aug 2009, at 2:05, Conrad Taylor wrote:

> Hello Cafe,
>
> I'm working at the moment on something quite interesting, but to me
> unfamiliar territory. I'm helping a project team to specify the
> design of what could end up as quite a large dynamic Web site, based
> on a Content Management System. The aim of the system is to function
> as an online school, using video tutorials to teach some practical
> skills.
>
> The principals behind this project created a document that described
> what they wanted the online school site to do. I was brought on board
> partly to advise on usability, but in practice they have come to rely
> on me to write the brief that is going to be shown to some agencies
> which specialise in Web and interaction design, to encourage them to
> tender and to quote.
>
> At the same time, I am aware of a few friends who are facing similar
> problems of coming up with a description of what a CMS-based dynamic
> Web site should do.
>
> What I am wondering is, what kinds of diagrammatic modelling
> techniques there might be for capturing and representing these kinds
> of complex systems.
>
> Through my membership of the British Computer Society, where I mix
> with database management types, I am aware of various techniques that
> exist for diagrammatically modelling relational database systems.
> Indeed we had a whole day's meeting on the subject this year. The
> favourite flavour there would seem to be Entity-Relationship
> Modelling, though one of the speakers made an impassioned pitch for
> Object-Relation Modelling as an alternative.
>
> Within our team, people have been happiest talking about "screens" or
> "pages", and what people ought to be able to do on those pages, or
> read from those pages. One of the things that I have been able to
> contribute to these discussions is a greater awareness that there is
> a database system and a bunch of clever scripts behind these pages.
> So, for example, if I am editing my personal Profile Page I can see
> that the current description of my interests is X, which means that
> has been projected onto the page from one field in a database; that I
> say that I want to edit this, which projects it into a window where I
> change the text; that when I press the Save button, the contents of
> that field in the database is updated. At the  same time when editing
> I press some check-boxes which indicate that I don't mind making this
> info available to my class tutor and virtual classmates, but I don't
> want other members of the virtual school to see this field. Those
> settings are going to update some other part of the database. And
> when my classmate wants to look at my profile page, the system has to
> check (a) that she is logged in with an identity and that it is
> therefore possible to tell that (b) she is my classmate, so she
> should be able to see my description of my interests when she looks
> at my profile page.
>
> It seems to me that if one were to create a rigorous diagram of these
> kinds of relationships, one would have to have a visual language to
> describe the interactions between the human user and the interface
> elements, and also a visual language to decribe the nature of the
> data elements involved (both those which control the interface
> elements, and those which drive the content of those elements and
> bits of information on the page). And between what lies beneath in
> the database and what appears on the screen, there will also be
> transformation processes that turn one into the other.
>
> I am painfully aware here that I am expressing myself clumsily. I
> want a kind of language that I can use to externalise our
> requirements and discuss them among ourselves and with the developers
> that we engage, and I don't know what it should be.
>
> Any observations on this problem would be read by me with great
> gratitude!
>
> Conrad
> ___________________________________________________________________
>
> Use the following address to post a message to all subscribers:
> [email protected]
>
> To subscribe, unsubscribe or change your options, visit:
> http://list.InformationDesign.org/mailman/listinfo/infodesign-cafe
>
> For all Information Design matters:
> http://InformationDesign.org
>
> Problems? Write to:
> [email protected]
> ___________________________________________________________________

------------------------------------------------
Lift: creative communication design
phone: +44 (0)118 948 4862 **New number**
mobile: +44 (0)7979 757983
aim: studiolift
web: http://www.studiolift.com

*This email is confidential and intended for the addressee only





___________________________________________________________________

Use the following address to post a message to all subscribers: 
 [email protected]

To subscribe, unsubscribe or change your options, visit:
 http://list.InformationDesign.org/mailman/listinfo/infodesign-cafe

For all Information Design matters:
 http://InformationDesign.org

Problems? Write to:
 [email protected]
___________________________________________________________________