I know that at least one or two web-design types sometimes meander through this blog, and I’d warmly appreciate a few seconds of advice from them. Trevor and I have to plan this site from the ground up, and it would help a lot if someone with experience and insight gave us a few tips on how to plan a site for the long run—structure, design, the macro-design sort of thing. We need to be ready if the site takes off, without presuming too much at the start. The last thing we need is to re-work everything from the ground up because we didn’t make our plan soundly at the start.
What should we keep in mind?
Après Edit
Shelley emailed me some helpful questions:
Q: “Are you talking appearance or server-side design issues?”
A: Not appearance, just now, but definitely server-side, structural issues. We’ll need help with appearance issues, but just now I’m especially concerned about the server end of the site design. Plus, we’re very likely to take advice about the server side, and more likely to be stubborn about our own taste in appearance issues. We should get off on the correct foot by showing ourselves cooperative; maybe it’ll become a habit.
Q: “What you might want to consider doing is setting up a separate area and start documenting what you hope to ultimately do with the site. This, then, will allow your friends to attach comments/trackbacks and give all sorts of advice about site structure and technology as well as design.”
A: Hey, that’not a question! But it’s a terrific idea. We should work on that one.
Q: “And what do you hope to do with the site?”
A: Well, we tried to answer that at the sketch of our plans, but we also don’t want to lock ourselves into a very closed design.
Q: “Do you see an interactive element to it?”
A: Well, partly—in the sense that we expect a Moveable Type installation, with multiple authors, comments and so on. We don’t anticipate having large numbers of authors dropping in and out sporadically.
Q: “Want multimedia?”
A: Sure! You got some?
Q: “In addition, what kind of security settings will you need? Will you need to have sub-sites that are password protected? Will you have multiple authors?”
A: Right now, I hope not anything more sophisticated than the usual password protection. But you surely know more about this than I do.
Thanks, Shel!
Posted by AKMA at January 23, 2003 03:55 PM | TrackBackIt's hard for me to read your blog body serif font in my Linux browsers, Galeon and Moz, unless I change the default font size to make it bigger. It may be because I don't have true type fonts there or something, but serif fonts look bad in my Linux setup. Anyway, you may want to try a larger font size in the CSS or a different font family.
Posted by: Stan at January 23, 2003 08:17 PMYou might want to take a look at Christina Wodtke's excellent book on Information Architecture:
http://www.amazon.com/exec/obidos/ASIN/0735712506/internettraining
I have my students read the webmonkey tutorial on Information Architecture, as well, and impress upon the importance of:
a) a design document
b) well-designed personas/scenarios as part of the document
c) development of a graphics-free wireframe before any backend coding or aesthetic design takes place
d) plenty of usability testing--even if it's what Nielsen calls "discount usability testing," with a small group of users. Feel free to e-mail offline for more details/info.
What kinds of structure make people feel they are part of a community? That seems to me to be very important for what you are doing. A place where the authors introduce themselves, certainly. Do you plan a place where involved readers could introduce themselves and a place where they could talk to each other? Will articles that are posted have a comment space after each one?
Posted by: Pem at January 24, 2003 08:24 AMSimplicity lasts forever.
Posted by: meg at January 24, 2003 04:29 PMI'd concur with what Liz has to say - if you're looking for some reading, I'd recommend Jeffery Veen's Art and Science of Web Design, and strangely enough, the book that Amazon sells at a discount with it, Don't Make Me Think (which has some great guidelines for that "discount usability testing") - both are fairly short and very pretty. :)
http://www.amazon.com/exec/obidos/ASIN/0789723700/qid=1043467363/sr=2-1/ref=sr_2_1/002-3128729-4048849
do think lots about your goals and audience before diving into the technical bits.
Posted by: Elaine at January 24, 2003 10:06 PMBut some variables are immortal. These variables are declared outside of blocks, outside of functions. Since they don't have a block to exist in they are called global variables (as opposed to local variables), because they exist in all blocks, everywhere, and they never go out of scope. Although powerful, these kinds of variables are generally frowned upon because they encourage bad program design.
Posted by: Garret at January 13, 2004 09:33 AMLet's take a moment to reexamine that. What we've done here is create two variables. The first variable is in the Heap, and we're storing data in it. That's the obvious one. But the second variable is a pointer to the first one, and it exists on the Stack. This variable is the one that's really called favoriteNumber, and it's the one we're working with. It is important to remember that there are now two parts to our simple variable, one of which exists in each world. This kind of division is common is C, but omnipresent in Cocoa. When you start making objects, Cocoa makes them all in the Heap because the Stack isn't big enough to hold them. In Cocoa, you deal with objects through pointers everywhere and are actually forbidden from dealing with them directly.
Posted by: Harman at January 13, 2004 09:34 AMEarlier I mentioned that variables can live in two different places. We're going to examine these two places one at a time, and we're going to start on the more familiar ground, which is called the Stack. Understanding the stack helps us understand the way programs run, and also helps us understand scope a little better.
Posted by: Thomas at January 13, 2004 09:34 AM