Page 13 of 27
Posted: Mon Sep 04, 2006 4:07 am
by onion2k
matthijs wrote:So has the design/frontend part been taken yet?
If not, I might be of help, if needed.
We'll need front-end people in two respects:
1. To develop and maintain highly flexible HTML with pure CSS layout .. Something along the lines of CSS Zen Garden. No layout whatsoever should be coded into the HTML, it should be entirely semantic markup.
2. To develop a demo shop with fancy graphics and layout based on the HTML and CSS from point 1.
Pop onto the wiki and join in!
Posted: Mon Sep 04, 2006 4:48 am
by matthijs
onion2k wrote:We'll need front-end people in two respects
Yes, I think there's a lot of work to do. That's why I thought any help might be useful
onion2k wrote:Pop onto the wiki and join in!
Ok, done!
Posted: Mon Sep 04, 2006 12:20 pm
by ok
I can help with PHP/MySQL/XHTML
Regards,
ok
Posted: Tue Sep 05, 2006 2:58 am
by onion2k
You'll need to add yourself to the
Wiki.
Posted: Tue Sep 05, 2006 4:19 am
by Jenk
has anyone got an example of an atleast half-decent use case document/code/picture/diagram/hand signal/morse code/wtf makes up a use case?
I'm utter parp at reading 'instructions' I need examples to learn

Hopefully once I have got the jist I can knock a few up

Posted: Tue Sep 05, 2006 4:51 am
by ok
I added myself to the wiki.
What I need to do now? When we start coding?
Posted: Tue Sep 05, 2006 5:36 am
by Jenk
once it has been designed.
Posted: Tue Sep 05, 2006 5:44 am
by onion2k
Jenk wrote:once it has been designed.
Which can't be done until we have a spec..
Which can't be done until we know the requirements..
Which I've started adding to the Wiki. People are more than welcome to edit/add more though.
Posted: Tue Sep 05, 2006 6:00 am
by Jenk
Indeed. I'm trying to read up on use cases as I would like to do this as 'by the book' as possible for a learning experience if anything.. I take it use cases are for defining requirements?
Posted: Tue Sep 05, 2006 6:40 am
by onion2k
Jenk wrote:Indeed. I'm trying to read up on use cases as I would like to do this as 'by the book' as possible for a learning experience if anything.. I take it use cases are for defining requirements?
I'd actually say that Use Case diagrams are for specifcation more than requirements. I've always written requirements as a list of everything I would expect the application to achieve, then written the specification as a formal outline of how the application would achieve the required features .. all the required data fields, code elements, design assets, etc. Not sure if that's the standard way of doing things or not though.
Anyway, I hate UML and everything associated with it.

Posted: Tue Sep 05, 2006 6:42 am
by feyd
Posted: Tue Sep 05, 2006 6:44 am
by malcolmboston
feyd wrote:I have to applaud you guys for building this by holding off on the urge to start coding and creating the specification.
Too true, i always dive in the deep end.....
Posted: Tue Sep 05, 2006 6:47 am
by sike
to get things started we should really just start with a bunch of bullet lists where we group requirements (e.g article, cart...). at a later stage we can build some more refined things upon that.
what i am trying top say is that we should not think too much about how we write / organize requirements but rather get things rollin'. it will evolve by time (sort of requirements refactoring (; )
chris
Posted: Tue Sep 05, 2006 6:49 am
by Jenk
We have such a list on the Wiki main page
feyd - everytime I see that dancing bannana I get the peanut butter jellytime track stuck in my head.[/offtopic]
Posted: Tue Sep 05, 2006 6:50 am
by onion2k
sike wrote:to get things started we should really just start with a bunch of bullet lists where we group requirements (e.g article, cart...). at a later stage we can build some more refined things upon that.
chris
We've got that. The main page of the Wiki is a list of general features, which I'm in the process of linking to seperate pages that give a more detailed list of requirements for the individual items. It's slowly going to build into a complete list of requirements. Unfortunately work is getting in the way of my fun right now.
sike wrote:what i am trying top say is that we should not think too much about how we write / organize requirements but rather get things rollin'. it will evolve by time (sort of requirements refactoring (; )
I don't really agree. Jumping into the code at this stage, prior to knowing what's really needed, will slow things down and lead to a similar sort of spaghetti mess OSCommerce is in at the moment. That's exactly what this project is trying to avoid. I realise it's not so glamorous and it's a bit boring for people who prefer to be coding than documenting, but experience has taught us that documentation first is very much the right way to go on a large project.