[e-users] Website Organization
Andres Blanc
wiki content we need to sort this project's face out. The current website(s)
and wiki(s) are a mess, to continue to add content without sorting this out is
simply a waste of time. As I see it we have three veins:
1. Project promotion (this includes news).
2. Community support and documentation.
3. Community resources and applications.
These three fit perfectly in three websites:
1. E.org
2. Trac
3. Exchange
But outside of this we have a wealth of internal sites and subdomains that is
a real mess, I can easily find 5 different guides of installing e17. We need
to cut this out and fit the corresponding content in the corresponding venue.
Before writing anything else let me say: We need to show Exchange more
love, in the backend and the frontend, to make it more appealing for external
application developers to announce their project news and updates there. This
produces dynamic lists and content we can reuse without effort and without
forcing them to create pages on our wiki and update some application table on
the wiki.
I didn't write much about exchange in the new TODO [0] and SITEMAP [1] files I
uploaded recently, but as I dig out and research what we have and the way other
similar projects are organized I realize that having a wealthy and active
exchange is a winning move.
[0] http://www.enlightenment.org/dev/README.html#todo
[1] http://www.enlightenment.org/dev/SITEMAP.html
I thought both of these files were more or less complete, but as I said the
more I dig the more I find and their content might be out of date compared to
this mail.
I ask you to review these files after reading this mail and let me know what
you think, we need to agree to some structure at least in our facade.
The other subject of this mail are the subdomains. I'm talking not about the
services they provide in the backend but what is presented when a simple http
request is done on the root folder.
http://forum.enlightenment.org/
We need an user forum but having users to register multiple times in
multiple sites is ridiculous so I suggest to REDIRECT this to a trac page
using DiscussionPlugin: http://trac-hacks.org/wiki/DiscussionPlugin instead
of the current forum.
I don't have the permissions to do this or anything else outside the SVN
tree but I would gladly take the time to install this if asked to.
http://svn.enlightenment.org/
REDIRECT to a wiki page that explains how to download either the full SVN
tree or specific folders, as an anonymous and as a registered user.
Installation of E17 is covered by linking to the installation section of
the E17 user guide.
http://docs.enlightenment.org/
REDRECT to a wiki page containing basically the same info, internal files
will be served as requested.
http://trac.enlightenment.org/
REDIRECT to http://trac.enlightenment.org/e/
http://packages.enlightenment.org/
REDIRECT to a wiki page containing the same info, Files that do not use
the repository system (like window packages) should be in Download and
pointed from the wiki page.
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.
There are other sites and subdomains that should be merged into these three
veins I talked about and can be found in the stage 3 of the todo list:
http://www.enlightenment.org/dev/README.html#stage-3-design-of-external-sites-and-doxygen
I have read all mails written about this in the past and I traced my plans
taking every idea into consideration, but if you feel I missed one make sure to
let me know.
------------------------------------------------------------------------------
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
enlighten...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users
Ian Caldwell
enlightenment.org/donate just isn't working ;)
> enlightenment-devel mailing list
> enlighten...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Carsten Haitzler
okie dokie... :)
> Before anyone else spends a second creating or editing existing website or
> wiki content we need to sort this project's face out. The current website(s)
> and wiki(s) are a mess, to continue to add content without sorting this out is
> simply a waste of time. As I see it we have three veins:
indeed. website was meant to be a simple 1-level deep brochure only. the
top-level links at the top were only meant to be as far as you had to click.
there's also too much e16 stuff thats prominent with not much on efl + e17 and
marketing and saying how great e is etc. :)
> 1. Project promotion (this includes news).
> 2. Community support and documentation.
> 3. Community resources and applications.
>
> These three fit perfectly in three websites:
>
> 1. E.org
> 2. Trac
> 3. Exchange
for now, #3 i'd put at the bottom of priority, and trac as #2. in the order you
have them. sold #1 first - then move stuff to #2 that has been ejected from #1,
or just put new content in #2. #3 for now put aside as thats more about data
and app downloads.
> But outside of this we have a wealth of internal sites and subdomains that is
> a real mess, I can easily find 5 different guides of installing e17. We need
> to cut this out and fit the corresponding content in the corresponding venue.
hell yeah.
> Before writing anything else let me say: We need to show Exchange more
> love, in the backend and the frontend, to make it more appealing for external
> application developers to announce their project news and updates there. This
> produces dynamic lists and content we can reuse without effort and without
> forcing them to create pages on our wiki and update some application table on
> the wiki.
sure - but AFTER #1 and #2 are sorted imho.
> I didn't write much about exchange in the new TODO [0] and SITEMAP [1] files I
> uploaded recently, but as I dig out and research what we have and the way
> other similar projects are organized I realize that having a wealthy and
> active exchange is a winning move.
>
> [0] http://www.enlightenment.org/dev/README.html#todo
> [1] http://www.enlightenment.org/dev/SITEMAP.html
>
> I thought both of these files were more or less complete, but as I said the
> more I dig the more I find and their content might be out of date compared to
> this mail.
>
> I ask you to review these files after reading this mail and let me know what
> you think, we need to agree to some structure at least in our facade.
>
> The other subject of this mail are the subdomains. I'm talking not about the
> services they provide in the backend but what is presented when a simple http
> request is done on the root folder.
>
> http://forum.enlightenment.org/
> We need an user forum but having users to register multiple times in
> multiple sites is ridiculous so I suggest to REDIRECT this to a trac page
> using DiscussionPlugin: http://trac-hacks.org/wiki/DiscussionPlugin
> instead of the current forum.
> I don't have the permissions to do this or anything else outside the SVN
> tree but I would gladly take the time to install this if asked to.
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.
> http://svn.enlightenment.org/
> REDIRECT to a wiki page that explains how to download either the full SVN
> tree or specific folders, as an anonymous and as a registered user.
> Installation of E17 is covered by linking to the installation section of
> the E17 user guide.
yes.
> 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
> http://trac.enlightenment.org/
> REDIRECT to http://trac.enlightenment.org/e/
i swear i made this work before.
> http://packages.enlightenment.org/
> REDIRECT to a wiki page containing the same info, Files that do not use
> the repository system (like window packages) should be in Download and
> pointed from the wiki page.
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.
> 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.
> There are other sites and subdomains that should be merged into these three
> veins I talked about and can be found in the stage 3 of the todo list:
> http://www.enlightenment.org/dev/README.html#stage-3-design-of-external-sites-and-doxygen
>
> I have read all mails written about this in the past and I traced my plans
> taking every idea into consideration, but if you feel I missed one make sure
> to let me know.
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
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) ras...@rasterman.com
Andres Blanc
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
Tom Haste
> 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.
>
>
<SNIP!>
Please take a look at the usage / page hit stats before yanking the
plug... I dont know where they are but cant comment, but if people ARE
using it and finding it useful, then it wont be the best idea to just
dump it. Keep it, just dont advertise or encourage it. Soon enough
usage will dwindle and then you can give it the coup de grâce. IMHO
anyway.
Toma.