[Grok-dev] Re: Suggested site structure
sebastian at urbantalk.se
Tue May 15 15:19:32 EDT 2007
15 maj 2007 kl. 20.20 skrev Martin Aspeli:
> Hi Sebastian,
> I'm impressed by your enthusiasm! :)
When I come across things I like... actually, I just enjoy putting an
effort up front. :)
>> Suggested site structure using the 4 E model (Excite> Educate>
>> Empower> Engage).
> Did you go to business school? :)
My background is more communications/marketing-oriented, but I have
been involved in a couple of start-ups and written my fair share of
>> I also suggest having the content mature over time.
> Most definitely. This will take some time. It's important that we
> don't have it look "unfinished" even if we plan to add more later,
>> ** Evaluate ** (Excite)
>> - Introduction screencast
> Personally, I think screencasts are an annoying way of presenting
> information, mostly because I don't have the patience to sit
> through them, and because I'm either in the office (when I can't
> turn up the sound) or at home but listening to music. But they are
> kind of "expected" these days and many people like them.
It's for the rest of us ;)
> I would have some first-order content that presents benefits in
> graphical and/or textual form, though.
My thoughts were to put that stuff in the overview. The screencast is
more "Look how easy we can make it look..." but the overview actually
shows what it's all about.
>> - Overview (history, philosophy, architecture, features,
>> business case ++)
>> - Case Stories (developer perspective)
> I think you mean Case *Studies*, but yes - good idea.
Freudian slip! We won't have any case studies (besides, they tend to
be a tad boring) or success stories to start with... so we could
write short case stories, in a tone much like what Apple does in
their Pro section (http://www.apple.com/pro/)
>> - Code
> I'd put simple code examples up front. At least I want to see this. :)
I agree. Code is often understated. Let's face it. Developers will be
doing a lot of coding, and reading Python code is dead easy.
>> ++ The Business Case is for managers
>> ** Learn ** (Educate)
>> - Recommended curriculum (suggested reading and learning path)
> Definitely. Helping people start in the right place and point them
> where to go next is paramount.
>> - Tutorial
> We need to make sure we keep on keeping this relevant and up-to-date.
>> - Sample applications
>> - Forum
> Why do we have Forum and Mailing list (below) in different sections?
I have an idea about putting a twist to the forum idea. I find a lot
of forums have a post saying "Read the FAQ before posting". In fact
forums usually contain a lot of great information. This could
probably be made more easily available.
>> - Online seminars (voice annotated h.234 screencasts)
> Heh. Crawl before you can walk. :)
This might sound wierd, but once you get the hang of it, I think it
will be easier to create a screencast seminar than it is to write a
short article on the same subject. No proof reading for example... :)
A dream would be to get Philipp von W to do the screencasts but with
just a bit more of an accent. I think that could become a classic.
>> ** Develop ** (Empower)
>> - API documentation
>> - Best practice (Howtos with sample code (and tests?))
>> - Templates (Application, component)
>> - Mailing list
> We've had success with using nabble.com and styling it for the
> Plone lists. See http://www.nabble.com/Plone-f6741.html.
Looks like a good option.
>> - Bug/feature collector
>> - Road map
>> ** Share ** (Engage)
>> - Guidelines
>> - Evangelist Blogs
>> - Mailing lists
> Another one? :)
> I'd keep the channels of communication together, otherwise people
> will fine one first and use it, whether or not it's appropriate.
True. Maybe start with one and then separate them if needed.
>> - Component directory
> Overall, this feels sensible, though.
> Grok-dev mailing list
> Grok-dev at zope.org
More information about the Grok-dev