Yay! This is the kind of feedback I was hoping for.
On Lunes 11 Enero 2010 10:32:34 Carsten Haitzler escribió: > forum - from my point of view - should either work properly as a first class > citizen or be ditched. i never use it - look at it or anything else. i think > most devs dont. having such a split community is bad. i'd rather have no forum > vs a badly tended to and not-attended forum. > Ok. We should remove the forum for the time being. Eventually we are going to need an outlet for the average E17 users to communicate without having to use a mailing list. But that is something we can take care of right before the final release. > > http://docs.enlightenment.org/ > > REDRECT to a wiki page containing basically the same info, internal > > files > > will be served as requested. > > what will u do with auto-generated docs? they are directly linked from the > current docs page The links to the auto-generated docs is static, like http://docs.enlightenment.org/auto/ethumb so it won't be a problem to mantain a wiki page for the listing. Also: > that depends - redirect just base or everything? the package pools for apt > need > to stay. but a wiki page would be good to hold that content. Only the requests for the root folder, sub-folders or direct file requests would be served as usual. I'm pretty sure apache is capable of this or in the worst case we simply use a php/js/html+link file with a redirect as index. > > http://download.enlightenment.org/ > > Should remain as the point of manually downloading anything E related > > outside SVN. We can update the look and feel of the directory listing to > > match the rest of the site and including links to wiki pages that might > > be of interest. > > that'd be nice. but yes - a simply download file tree is whats good here. > anything else (wiki, main site etc.) will invariably point to specific files > or > directories here. We only need to move the window packages here to make this true. Editing the files Apache uses for header/footer of the directory listing should not be that complicated IIRC. So this isn't very far from being done. > ok - sitemap... this needs attention. home page probably should be what it is > now - or roughly. artists - not sure that gets a whole page? well not at this > stage. but the most important thing here is - download... where? main page and > no main links to download. that should be a main page that points to: svn, > source tarballs/releases, package repositories. > > if there is a whole desktop link - there should be a whole "devices" or > "embedded" or "mobile" link. as such i think desktop should just be dropped. > or > maybe changed to something that covers everything efl does I'm going for the Enlightenment is a Developement Libraries project approach to the website in which the "desktop" page is supposed to be a "Featured Application" page which can change in a distant future, by the time the community around E17/18 gets large enough to warrant its own portal. I planned to add the download information in each page, since there are (at least) three ways to acquire either E17 or the EFL (packages, snapshots, svn) each with its own instructions, including differences for ubuntu or opensuse repos In the end there is no download and double-click to install outside of the window packages, which also have some instructions of their own. My idea was writing the instructions as wiki pages linking them from the corresponding brochure site for either the Desktop or the EFL as a list. In the end the people would go home->EFL->SVN or home->Desktop->packages for example. This approach can be easily replaced or duplicated as a catch-all download page. The reason I gave artists its own page was mainly due to the fact that Edje features IMO make up most of the reasons a developer would choose the EFL over any other competing library, unless he is doing embedded development in a device that doesn't have enough resources (or is not compatible) for most of the competition (a rarity in new devices). While the page is named artists and explained in simple terms the actual target are developers who are looking for something different that what we have today. But I agree there is not exactly a wealth of content for artists, but we have to make one before release if we are to get devs interested as soon as they look at the home page. Otherwise I believe many devs will simply go "not another widget lib!" and close the tab. I can´t blame them when a new widget lib is released every other day. These are just opinions of course, I'm not trying to force them into the site I just wanted to make sure the rationale behind my ideas is clear before we decide what to do. In the end we all need to agree in the following question: Is this a Development Libraries project or a Desktop Shell project? You can't have both living in the same facade, even the KDE people decided to make this clear recently, see: http://dot.kde.org/2009/11/24/repositioning-kde-brand In the end you have either a Desktop Shell producing development libraries or have Development Libraries that happen to be used by a desktop shell. This changes not only the website structure and content, but also the approach to documentation, exchange and anything else facing the public. Depending on that answer other questions arise, but we should let that for another mail. For some the answer might seem obvious but when you really spend the time it takes to review the project's past and current history (and content) its not clear what everyone agrees. dresb ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ enlightenment-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-users
