[Grok-dev] Re: Suggested site structure

[Sebastian Ware]

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  
business plans...

>
>> 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,  
> though.
>

Very true.

>> ** 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.

Regards Sebastian

>
>>   - Component directory
>
> Overall, this feels sensible, though.
>
> Martin
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev