I've updated the mockup with a sidebar to show the structure a bit
I think this is mostly like what you've described.
Other changes are a simple menubar and the platform icons on the main
page that we decided we wanted back.
"where do we put documentation like:
which is not features
oriented but goes into the category setup "
This should actually go right below the download options (see the second
page in the mockup). There will also a link to it in the Docs sidebar.
It's a bit hard to explain in an email, I think the mockup explains it
On 20/01/2014 17:31, Corinne Krych wrote:
I think the original idea was to have a common text. I think we could have common part
(section on pipe)
(section Pipeline & Pipes)
all defined Pipe and pipeline, they could have a common part but of course this will
involve some serious documentation refactoring.
=> first task make common smaller pages
However, we still need platform specific text. In all the previous exemple we give code
snippet + code explantion. We could extend the tab to include text + sample.
What will be nice to have as a POC is also:
- the main documentation page with the 3 features section: Core/Push/Security
- when we pick core, the display of the list of features: Pipe, Store etc…. which is
actually missing from Hylke draft.
- where do we put documentation like:
which is not features oriented but goes into the category setup
I’ll fork your branch and try to see how we can refactor documentation and give you more
concrete feedbacks shortly.
For the menu color I guess the best person to help is Hylke.
On 20 Jan 2014, at 12:44, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko <kpiwko(a)redhat.com> wrote:
> Looks good!
> +1 I like the dracula theme !
> plans to support platform related text?
> E.g. pipes on Aerogear can be used within FragmentActivity, which is valid for
> Android only; Javadoc is not related to iOS, etc. That's basically a merge of
> our guides into a one per feature with information covering all the platforms.
> Which brings me to and idea of global platform switch. User/reader can switch
> platform once and all code snippets and platform related blocks are
> automatically selected. Can also be session based and affect all pages user
> +1 , that would be really cool. I came accross such a layout on
, check on the right, you have a tab where you can switch between different languages, the
snippet is updated.
> There are also some online apps that does the job for you like apiary.io and
> On Mon, 20 Jan 2014 11:37:28 +0100
> Erik Jan de Wit <edewit(a)redhat.com> wrote:
>> What I get from this thread is that we like the colour section idea, but we
>> don’t want to re structure the entire site. So what we need to discuss is how
>> are we going to use these sections if we don’t restructure. What I like about
>> them is that it emphasises that our API’s are similar for all platforms and
>> that we only have one document explaining for instance what pipes are. But
>> the menu, doesn’t fit into this new colour scheme, so we need some decisions
>> about how we are going to move forward.
>> Based on the work Corinne did with the introduction of sass I’ve had a go at
>> implementing a bit what Hylke proposed, have a look at my sass branch
and the page I’ve updated
>> to be in section layout. Don’t look at the header and footer as I haven’t
>> changed those.
>> There are a couple of things that I don’t like about the current
>> implementation, to enable the code blocks I’ve added some html into the
>> asciidoc and some jquery magic in the layout. Maybe we could make this better
>> by chaining the rendering/backend or by introducing some sort of plugin into
>> asciidoc? Other then that, I’m sure Hylke sees a lot of things that are still
>> off, but it’s a start.
>> What do you think?
>> Erik Jan
>> example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff
> aerogear-dev mailing list
> aerogear-dev mailing list