Content vs presentation.

I'm with you 100% on that workflow TroubZ, I just finished something in a similar vein following that approach in geting the form looking correct building in it's validation just cycling through the same page and actioning of to a test page just to finish the cycle as such and retun to itself with that done I know the front end works and looks right and is presentable then I can work on the rest of the backend functions without thought to that front end again and just bolt the bits together.

Triumph I'm not sure that I like the templating engine approach per se, it worries me that we take code we know and then stick another layer of lets say psuedo code in to the mix that is to all intent and practise particular to a given engine.

I'm more keen on getting to grips with working within a framework that ties one in to a disiplined workflow and as much as I understand it that's the MVC model, however these frameworks being discussed do by their nature arrive at a point with the control/view aspect of the code where they are templating even if that is just by the nature of the helper classes called into the html.

Hugo.

Troubz

The code I gave you for the web page you did was deliberately made so that, once you had the page done and ready as html only, you could cut and paste the bits into the divs (and notice that the design I gave used ONLY divs, as I personally believe these ARE acceptable for style only additions to initially formed semantic html) or rename the existing divs in that initial code to match.

I tend now to use div id's that match those I used in that sample page code. ID's used SHOULD be descriptive for the reader to understand what's in them.

CT

I know some people advocate using HTML wireframes, but wouldn't all this sort of stuff be better off worked out at a precoding stage, ie with a series of diagrams on paper etc.?

that is quite an interesting workflow. I'm gonna try it out next time to see how it works out.

Hmm, let me explain in this way...

In the building industry, there are blueprints that have standard symbols.
No mater where you live in the building food chain you can look at a blueprint and know exactly what has to go where. What it will be made of and what it's dimensions need to be.

There is no such medium for software.
The only medium for software is software.

Take this example of a technical description.
I want you to build me a house with 4 bedrooms, two bathrooms and a living area - big enough for a pool table.

Now the vision in my mind of what the house is going to look like will never, ever match that of the builder's.

None the less the builder goes off and bulds me my house based on my description. and calls me up in a few months time to let me know it is done. Because it wasn't initially specified, he made it out timber - but I really wanted brick.

We also notice that I didn't mention how many doors/windows were required in my new house - thus it came with none.
A lengthy and costly rebuilding / refactoring must now take place to retrofit the original built house with the new requirments.

But more words aren't the answer. Let's say I gave the builder a written description of my house that was so flooded with wordy descriptions that the specs now take up two volumes - (not unheard of in application development. The exra words still haven't helped the builder to build me exactly what I want - there is still a level of "guesswork" required to transform written words into my building.

Same goes for software - more words in the technical specification is not the answer. Written instructions are just simply a poor medium for software development and are only ever used for assigning blame when the *beep* hits the fan!

Interesting topic.
It souds like you are talking about Feature Driven Development or another similar form of Agile development.
There are many ways to cook an egg.
No development methodology will be perfect for every project. I like Agile development because of it's flexibility.
With many of the project's I work on we don't have enough access to the client.
Some projects are design driven, usually they are simple sites we are given a design we build a shell of a site and wait for months while the client develops content.
Some are functionality driven.
Some are driven by content.
Personally I like to get all the content and functionality sorted before the design.
I come from a development background.
The designers like to design the site as though its print material and we then have to develop the functionality to match the signed off design.

When I said to use paper, I didn't mean to fill it with words, I meant diagrams.

I'll admit that I've never worked on any large applications so I don't really know how the process works and I'm only going on what I've read in articles on information architecture, usability etc but a common theme seems to be that before a computer is even touched that everything is drawn up on paper by hand, with whole scenarios that would be acted out storyboarded across many sheets of paper or card.

It's hard to keep the graphics people out of the loop until function and usage are designed in. It is the rare print trained "designer" who gets it where the web is concerned. They have no understanding of an interactive, shapeless medium.

Their job must be to complement the web page's form and function, not to be the driving force. The web page is the user interface; it's what the visitor uses. It's way too important to leave to the graphics people. OK, let them have a shot at the five page brochure site. Keep a baleful eye on them, though.

cheers,

gary

I'll admit that I've never worked on any large applications so I don't really know how the process works and I'm only going on what I've read in articles on information architecture, usability etc but a common theme seems to be that before a computer is even touched that everything is drawn up on paper by hand, with whole scenarios that would be acted out storyboarded across many sheets of paper or card.

Tyssen,

You're not far from the FLiP prescribed path.
FLiP states that you should use a wireframe as the storyboard / rough draft (1st Step) of your application.

The following is such a beast;
http://www.gm.rmit.edu.au/sec_card/wireframetool/index.cfm

FLiP also teaches us that the user can't telll you what they want until they see it / until they play with it.
By providing them with a clickable / usable storyboard you straight away get their enthusiasm and involvement up to a level that assists you as the developer.

The 2nd step is the HTML only prototype again you can check one out here (note how there is a comments frame that allows the users/developers to communicate with each other with regards to making changes about any page in the prototype;
http://www.gm.rmit.edu.au/dev/security_app/prototype/index.cfm

ITIL (IT Infrastructure Library) (A set of guidelines for best practice in IT - Originally developed by the British Government) states that it isn't necessarily which process you follow - as long as you actually have one to follow and actually do follow it.

So it is a matter of horses for courses and finding the one suits your style and is also able to fit in with your work place. I have to admit, that I was very suspicious of FLiP when I first started using it - I just couldn't get my head around it.... How could I possibly write technical documentation for an application when I don't know things like database/table/column names etc at the time the documentation is written or how can I possibly write the unit test before the code that the test is for?... it took me about three applications for it to really sink in... but it only took the first one to realise how much more successful the application I finally delivered was by using the new method.

Feel free to have a play with both the wireframe and prototype if you get the urge.

Thanks for the links, TroubZ, they're pretty interesting. Like I said, this isn't really my area (although I read about it from time to time) so it's good to get different perspectives. :thumbsup:

If we're going to keep on with this thread, can we start a continuation. Its a pain to have to see its been updated in recent posts, click on the thread, scroll down to the bottom of 50 posts, click next, scroll down to the bottom again.

Tony
... is there an update which allows the link in recent posts to go straight to the unread posts in the list?

... also is there an update which displays the bottom of the thread after posting?

just gone through all that pain just to see that it's a post about the pain of having to go through said procedure, you've got to laugh!

Actually, I've figured out if you click on the bit that says "1 new post" you go to that post - at least on single page threads. I missed my click on this thread.

Just tried that only to find a post suggesting it,
erm no it doesn't work for multiple pages

Damm!

Drat!
A post saying Damm!

Of course the 'home' key and 'end' key greatly speed up scrolling.

Some of the new logitech mice have buttons (iirc, "flip") to take you straight to the end. Unfortunately, I'm viewing this on my mini (and the mouse doesn't have Mac drivers).

under the appearance preference pane in OS X you could select the 'jump to here' in the click in the scrollbar settings. That would a least keep you from scrolling. You could also use command down arrow to jump to the bottom of the page.

I'm using x-gestures and camino. I've now set up down+up and the same as command+down arrow.

I guess I shouldn't use that as in FF gestures that would be reload page. It doesn't have anything for go to end.