<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hey everyone,<br>
<br>
So we've been doing continuous improvements to the website. Corinne
and Erik have been making some awesome progress shaping up the new
documentation section (roadmap here:
<a class="moz-txt-link-freetext" href="http://aerogear.org/docs/planning/roadmaps/AeroGearWebSite/">http://aerogear.org/docs/planning/roadmaps/AeroGearWebSite/</a>)
according to the mockups
(<a class="moz-txt-link-freetext" href="https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-project.png">https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-project.png</a>).
We've split stuff up into "Setup Howtos", "Examples", "API
Documentation" and "Guides". I don't think there was much
controversy here and there's been made some headway already in
unifying some of the documentation.<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div class="ace-line" id="magicdomid610"><span class="">The most
important change in the website mockups was that instead of
focusing on platform branding, the focus is on solving use cases
that “we happen to support on these platforms”. So
Core/Push/Security are the main players over iOS/Android/JS,
although these are still referenced everywhere and presented in
a graphic on top of the home page.<br>
</span></div>
<br>
Before we can work on the project homepage sections and download
areas of the website we should have a discussion about how the
AeroGear project itself is structured. The project seems to have
grown organically and new modules have been added here and there.
There are some of these that make the structure of the project more
complicated that it needs to be (in my opinion) to present it in a
simple way to developers visiting the website.<br>
<br>
I've done some research on the project structure and have written
down the findings, as well as points where there's room for
improvement and possible solutions, here:
<a class="moz-txt-link-freetext" href="http://oksoclap.com/p/AeroGearModuleUntangling">http://oksoclap.com/p/AeroGearModuleUntangling</a><br>
<br>
TL;DR: The most important questions that we need to answer are
these:<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div class="ace-line" id="magicdomid548"><span class="">- “If I
download a library on one platform, what must I download to use
the same features on an other platform?”</span></div>
-<span class=""> "Is this a part I use on the client, or on the
server side?"</span><br>
-<span class=""> “What do we mean when talking about different
AeroGear subprojects/modules?”</span><br>
<br>
One solution might be:
<a class="moz-txt-link-freetext" href="https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-modules.png">https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-modules.png</a>
I've made a lot of assumptions here, and it might not work, but I'd
like to hear your thoughts on it.<br>
<br>
It would clarify a lot if we could harmonise the different downloads
across platforms, either by providing single download solutions or
splitting everything up and naming all the parts consistently. I'm
interested in what the technical issues might be, as I wasn't around
when most of these decisions were made, or I simply missed them.<br>
<br>
Thoughts or other ideas? :)<br>
<br>
Thanks,<br>
<br>
Hylke<br>
</body>
</html>