We use a UI focused design process as well. Start by getting the business intent for the website (why bother?), then a list of roles (including non-human roles like web service consumers and exports and the like) and the intent for each (what do they get out of using the system). We then brainstorm a list of tasks (basically use cases - call them tasks as non-technical users "get" that name more easily) and then come up with the subset of essential tasks (essential use cases) required for the site and all of the essential roles to achieve enough of their intent for them to use the system (we always try to keep projects small and to grow them over time).
>From there we create the screens, actions and steps (within the actions) to fully specify each task (using an iterative process to lock down more detail each time around), starting with the object and screen type - product list, user view, etc. and then getting the parameters that relate to each screen type. For instance, a list screen requires a list of attribute names to display, a list of any per object control actions, the default order by attribute(s), the default filter by attribute(s) and any other filters required as well as the paging and ordering features required. Every screen type has its own little domain specific language so screens can just be added to a metabase and generated. For a green field application, you can automatically derive a naïve database schema just by a list of objects, relationships and the attributes to display, filter by and/or order by on all screens (including imports and exports and notifications as "screens" to capture all I/O requirements). There IS however a limitation with this approach if you are working with a legacy data source as the requirements may not match, so I keep a copy of the db schema to hand and when I go through the field lists for each screen I ask the user if they ask for something new where we will get it, etc. I tend to do smaller projects and this approach works extremely well. Bear in mind for larger projects that functional requirements (which is all that this captures) is not the whole set of requirements. There are whole classes of non-functional requirements from OS to browser to performance to peak load to physical network structure that may also affect the design. There are plenty of checklists around for capturing non-functional requirements, so you may want to Google for those (our projects are small enough that we get to define the non-functional requirements and include them in the original quote as limitations - we only have to change them occasionally for a client that really needs their site to work on a PPC or whatever. Best Wishes, Peter On 11/8/06 10:22 AM, "Sammy Larbi" <[EMAIL PROTECTED]> wrote: > Hi Gus, > > Steve Gustafson wrote, On 11/8/2006 8:21 AM: >> >> For me the application dictates whether I build from the front-end or >> back-end. >> >> As the complexity of the back-end increases, I am more likely to begin >> there. The reason for this is it is very easy to build a UI that does >> not match the requirements of the back-end. For a simple application >> this is not the case, but if you are building an online banking >> system, you better nail down the back-end before you think about the UI. >> > I haven't experienced that. I can certainly see how, if you are letting > the UI drive your database design, that would be the case. But here, my > understanding was that we are simply getting feedback from the users > before doing the database design, to help inform us of the requirements. > Of course, I have heard a horror story from a close friend > (incidentally, the app was for banking), where two separate teams > designed UI and db, and the UI team's design "won out" but it didn't > make sense from a data perspective. I wouldn't say you need the db > nailed down, but certainly you would come up with prototypes based on > some (albeit incomplete) knowledge of how the system should work. At > this banking company, the UI designers were clueless, as I was led to > believe. > > With all that being said, I would think the best way to do this learning > process is to not heavily couple the UI or DB designs to anything in > particular at this point (or ever). You ought to be able to reuse your > database among different UIs, should you choose to do so. > > -Sam > > >> That being said for a very high percentage of applications building >> around the UI is fine. >> >> Gus >> >> ------------------------------------------------------------------------ >> >> *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On >> Behalf Of *Brian Klaas >> *Sent:* Wednesday, November 08, 2006 8:27 AM >> *To:* [email protected] >> *Subject:* Re: [CFCDEV] Application design ideas >> >> I always tell my staff that ³The interface /is/ the application² for >> the users. Building the interface first will save you countless hours >> down the line by removing a large number (but not all) of the ³Oh, I >> thought the application would...[insert name of feature here]² and >> ³Couldn¹t you just change this to...[insert description of new feature >> here]² conversations that you¹re likely to have. >> >> brian >> >> >> on 11/8/06 7:14 AM, Hal Helms at [EMAIL PROTECTED] wrote: >> >> Yes, I would, Stephen. Here¹s why: only users can tell us both exactly >> what they want the system to do and, very importantly, what the system >> should look and feel like. (I¹ve seen many times when a perfectly >> functional system is never used because the fit between system and >> user is a poor match.) We would LIKE for users to be able to tell us >> what they want, but experience shows us they¹re much better doing this >> AFTER the fact (which is why so many requirements come out at >> deployment in the guise of ³You know what would be nice² comments). >> Doing the UI first allows all this discovery to be done before the >> cost of code and database work is paid. >> >> >> *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> *On Behalf Of *Stephen Adams >> *Sent:* Wednesday, November 08, 2006 7:07 AM >> *To:* [email protected] >> *Subject:* Re: [CFCDEV] Application design ideas >> >> >> Hi Hal, >> >> >> >> Thanks for the reply, the application I'm building is a Flex front-end >> based application, do you think it's a good idea to build a demo >> front-end in Flex first? >> >> >> >> On 08/11/06, *Hal Helms* <[EMAIL PROTECTED]> wrote: >> >> Stephen, >> >> >> >> Here's how I approach things. After I have a decent idea of what the >> system needs to do (the features of the system in your list), I begin >> creating the user interface. Designing the UI first is the best way I >> have found to fully capture all the nuances of the system. Because >> there is (almost) no code and no database involved, I remain very >> flexible as I iterate over many versions with the client. My goal is >> to capture all of the requirements within the context of a very usable >> system. If you've not done "UI First", I can't recommend it highly >> enough. >> >> >> >> Once this is done, I'll create the UML and, finally, the >> persistence/DB layer. >> >> >> >> HTH, >> >> Hal >> >> >> >> *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> *On Behalf Of *Stephen Adams >> *Sent:* Wednesday, November 08, 2006 6:23 AM >> *To:* cfcdev >> *Subject:* [CFCDEV] Application design ideas >> >> >> >> Hi, >> >> I'm thinking about how I go about designing an application from >> scratch. I've got a wireframe diagram of how the system should look, >> all the pages and what they will contain, but I trying to think what >> to do next. Do I: >> >> * Create the database >> * Create UML diagram >> * List the features of the system >> >> I'm building this system with a Flex front end so its got to be very >> OO orientated, but where to start. Does anyone have any ideas, >> thoughts, what do other do? >> >> Stephen >> >> You are subscribed to cfcdev. To unsubscribe, please follow the >> instructions at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com <http://www.katapultmedia.com/> >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] >> <http://www.mail-archive.com/[email protected]> >> >> >> You are subscribed to cfcdev. To unsubscribe, please follow the >> instructions at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com <http://www.katapultmedia.com/> >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] >> <http://www.mail-archive.com/[email protected]> >> >> >> You are subscribed to cfcdev. To unsubscribe, please follow the >> instructions at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com <http://www.katapultmedia.com> >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] >> <http://www.mail-archive.com/[email protected]> >> >> You are subscribed to cfcdev. To unsubscribe, please follow the >> instructions at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] >> >> >> You are subscribed to cfcdev. To unsubscribe, please follow the >> instructions at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] >> You are subscribed to cfcdev. To unsubscribe, please follow the >> instructions at http://www.cfczone.org/listserv.cfm >> >> CFCDev is supported by: >> Katapult Media, Inc. >> We are cool code geeks looking for fun projects to rock! >> www.katapultmedia.com >> >> An archive of the CFCDev list is available at >> www.mail-archive.com/[email protected] > > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions > at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
