[consulting] DrupalCOM: european Small Business distro

[Jose A Reyero]

Bèr Kessels wrote:

>Hello,
>
>Quite a while, already i have maintained a local configuration and patches of 
>Drupal, which I called drupalCOM. We are reviving this, and I would like some 
>feedback.
>  
>
What we need is a sample site so people can see it before downloading
and could be a good starting point for these discussions.
Then maybe the ability to download and set up a demo site with all the
content and configuration. It is usually easier for people to start with
a running site, and then go editing/removing/adding pages as they need it

>I would love to hear from you people how you think a drupal for small 
>enterprises should look. I am aiming at those brochure sites, mostly in 
>Europe (multilinual!). 
>  
>
Multilingual++ :-)

>I want to re-think this and not look at it from a technical point, but just 
>make a list of what is needed functionality wise, rather then what modules 
>should we have, what must a theme do etc. please keep this in mind when 
>adding your ideas: I do not want to talk about modules, themes, what 
>can-be-configured-how, etc.
>
>(also look at http://drupal.org/node/31896)
>
>* Able to add hierarchical data, to gather usefull articles etc (about, route, 
>prices, philosophy etc)
>* Able to add and remove single pages in a simple menu (about us, etc)
>* Maintain a few lists with articles, for products or services
>* Maintain a list of recent articles (blogs, news), with a configurable date.
>  
>
And maybe stop thinking about abstract 'hierarchies' and start thinking
about 'real things'. I mean I'd like to be able to add a "product" and
see it showing up in the "product catalog" without messing with menus or
taxonomies. Or add "company information" and see it just showing up in
the main menu.
For this we'd need to define simple content types with a predefined
behaviour, like
- Product
- Service
- News
- Page (company information)
Each content type should 'know' by itself where to go in the main or
secondary menus. And save taxonomy for additional classification, like
classifying products in product types, or having different types of news

>* Simple managment of one or two custom blocks. 
>  
>
No 'blocks', but meaningful concepts, like 'Product catalog' with an
option to show up in the main page or in the side bar and the ability to
add images for each product category and produce a nice block for the
main page with some dynamic effect.
People loves pictures and simple dynamic effects, like them changing on
mouseover. So I'd say a big part of the success of this initiative will
be determined by the 'nice blocks' we can show up in the main page
without custom coding.

>* Simple, single, contact form, possibly with saving feedback on-site.
>  
>
I think the contact form must be a bit more configurable. Do they want
to know your name, age country, etc? Will they use it as marketing tool
or for technical support?.... For that we need fully configurable forms.

>* Search
>  
>
And site map.

>* Each artilce and page has a coounterpart in another language.
>* Simple image managment in two ways:
> ** add fancy images to about us pages, to contact forms etc. (aka, learn the 
>f*ing HTML, with a simple upload system) 
> ** Add simple pre-styled images to news/products. (like image module)
>  
>
I'd prefer replacing 'simple' by 'powerful' or 'flexible'. These
marketing people loves the ability to add images of any size anywhere,
or maybe SWFs instead images.
And what we are talking here is a site with a single admin who's
suppossed to be able to learn at least a little bit about putting images
here and there.

Btw, let's not forget the ability to download attachments, like 'PDF
brochures' which I dont know why are everywhere in this kind of sites to
download product information or product catalogs.

>* Clear and transparant admin/moderation interface.
>  
>
I'd add one more layer for admin interface, a 'company oriented one'
where you can set up 'company name' instead of 'site name' or enable
disable 'products', 'services', etc.. Then we can keep the more lower
level one -current one- for fine tuning if needed.

>It is also good to note what should NOT be included: 
>* Login / advanced user management (log in for moderateors only)
>* Comments, forums, trackers and other tipical community ware
>* User/post/date details on various pages, including in search!
>* Moderation qeues, promoted entries, and other community-centric workflows.
>
>  
>
Some workflow concepts may have some use, like 'promoted' for products
or news.
I.e. we could translate the 'promote' option into 'show up in the main
page in its own block' or 'show everywhere in a side block'

>Now the funny thing with all this is: its so darn simple!. It is so simple, 
>that drupal cannot do it! Drupal adds complexity all over the place. And most 
>often the biggest bulk of the work lies in getting rid of that complexity and 
>getting rid of all these pages, links, read-counters, attachement-lists, 
>user-profiles, post-dates, and what more. 
>  
>
Well, we only have to hide that complexity for end users maybe with an
additional 'function oriented' configuration page. Then we could have a
module for 'compay site' administration that could hide in a lower level
the current administration interface. I wouldnt get rid of it, just hide
it and dont show it unless the site admin wants to dig deeper...
The funny thing is that adding options for administrators to hide
complexity from end users will eventually add complexity for low level
administrators :-)

>And yes, i have heard this too: Drupal is probably not the best app to do 
>this, since it is aimed at communities. But there is no proper alternative. 
>Quoting Boris:  Drupal s*cks least. The other good part about Drupal is that, 
>if a client decides she wants all this, but also a forum, its there!
>  
>
I think Drupal is 'still' a good tool for that, I mean for building any
kind of site.
That 'still' means that if you follow the development in the latest
releases, we are _adding end user functionality_ into the core instead
of _adding just options_ into it, which would be better if we think of
building general purpose sites.

>Please give mee feedback on what you people think would be wrong and / or 
>different in this? Or what you are missing.
>  
>
I'd add simple newsletters users can subscribe to without logging in,
and these subscription forms usually ask for some other data like age,
preferences, etc.. Or maybe this should be merged with configurable
forms,  like a 'subscription option'