[aerogear-dev] Website restructure

Wed Nov 27 04:42:24 EST 2013

+1 for Sass

On November 27, 2013 at 7:20:32 AM, Corinne Krych (corinnekrych at gmail.com) wrote:
>
>Thanks Jay for giving us feedback.
>
>+1 on building on existing website
>
>To fit color code from Hylke, we need to adjust the light grey, pastel colour we used for more contrasted colours.
>
>Thinking ahead about this colour revamp, I've delved into CSS preprocessor. I think aerogear.org would benefit using one:
>- with help of variable, changing colour, size etc.. is made easy. Help defined color palette.
>- with @media and mixin, responsiveness is made easier to maintain
>- and much more.. the good thing is you can apply/create mixin as you go and refactor in iteration
>
>I've done a first trial with SASS on that branch [1].
>Similar work a bit less in details though with Sylus [2].
>
>Choosing which preprocessor to use is like choosing which color fit you well.
>
>I personnally go for Sass. I like its maturity, strong community. Latest addition Scut [3] has interesting set of mixins. I was impressed by sass reverse engineering command that let you move your CSS to sass file. it works like a charm.
>My second choice would be Stylus. As we're using some Topcoat's component (menu).
>Last option is Less.
>Here a presentation I'll give next Thursday on preprocessor topic [4].
>
>Let's move forward, if Hylke can pick colour on we could start with revamp colours + CSS precporcessot
>Then add some refactoring on main page content. I'd like to break it down into several JIRAs to avoid too big PRs syndrome.
>wdyt?
>
>++
>Corinne
>[1] https://github.com/corinnekrych/aerogear.org/tree/sass#building-css
>[2] https://github.com/corinnekrych/aerogear.org/tree/stylus
>[3] http://css-tricks.com/introducing-scut-new-sass-utility-library/
>[4] http://corinnekrych.github.io/preproCeSSor/
>
>On Nov 25, 2013, at 3:41 PM, Jay Balunas wrote:
>
>> Hi All,
>>
>> I'm just going to reply to the original email. There has been some good discussions in the thread though and for the most part I agree with other emails.
>>
>> Most of my comments will be inline, but in general:
>>
>> I like the idea of using colors and lots of your ideas around APIs, doc areas, etc... My main concern is about drastically changing the current site as we've had several redesigns ( a couple before you came, and then you last one, and this proposed on). I'd like to make sure we explore integrating some of your ideas, but keeping core aerogear.org site mostly intact. So lets work on color scheme's, content updates, API/coding presentations, etc... within the context of the current site if at all possible.
>>
>> On Nov 4, 2013, at 10:24 AM, Hylke Bons wrote:
>>
>>> Hey everyone,
>>>
>>> So Jay asked me to look at how the website content is structured and how
>>> to improve it. Since we have so much content, it gets confusing very
>>> quickly.
>>>
>>> https://raw.github.com/hbons/aerogear-design/master/aerogear-project.png
>>>
>>> Here's a mockup of a possible solution. I'm better at explaining things
>>> in pictures than in words, so please have a look. I'll explain things in
>>> more detail below.
>>>
>>> I've tried to keep every subproject use case based, and explain the use
>>> case before features. See this as a bigger picture, and don't focus on
>>> the graphic design too much, it's there to help explain the structure of
>>> the project, and is not necessarilly a final graphical design in any way
>>> (though if you like it we can make it work!), but I wanted to show how
>>> different colour palettes can help explain the project and give a better
>>> sense of where you are on the website.
>>
>> As I mention I really do like the color coding, and especially being use-case driven. I also agree with corrine that on the home page I'd like to make sure we keep the platform icons (I like those a lot as well), but perhaps work in use-cases (below, above, etc...), or use case drive in the sub-pages?
>>
>>>
>>> I've done a lot of research on the project, but some things may be
>>> wrong. So your feedback on that would be greatly appreciated. Even after
>>> spending many months with the project, I still don't fully grasp
>>> everything (which shows part of the problem).
>>>
>>> 1. Naming
>>> I've split up the project into three main subprojects: "AeroGear Core",
>>> "AeroGear Push", and "AeroGear Security". These three are the main focus
>>> and use different icons and colour codings throughout the website to
>>> guide people. Each subproject has "client" and "server" components.
>>> Server pieces being appended by "Server Component" and may be standalone
>>> or an addin to something. Client (API) pieces follow "Project.Namespace"
>>> format. This way, there's never any confusion about what we're talking
>>> about in the documentation and marketing materials.
>>>
>>
>> +1 on color scheme - and agree with server/client aspects of each. We really have 2 matrixes here; platform (iOS, Android, etc..) & feature (use-case) perhaps there is a paradigm or structure to showing both somehow?
>>
>>> 2. Documentation
>>> Splitting up documentation. "documentation" can be a broad term. I
>>> suggest splitting it up in three parts to easily find what you're
>>> looking for: "Setting up" (downloading and boatstrapping a dev
>>> environment), "Examples" (how to use the API in your environment to get
>>> started), "API Documentation" (speaks for itself), and "Tutorials"
>>> (setting up more complex environments and API usage). This covers most
>>> of the documentation that is currently on aerogear.org and will make it
>>> a lot easier to browse.
>>
>> +100 our doc sections needs a good cleaning, organizing, and a better way to navigate and view.
>>
>>>
>>> 3. Coding languages
>>> Where the API is unified across all platforms (hopefully most of it), we
>>> can generalise example docs, and show a switcher for code blocks that
>>> shows how to do a certain thing in a particular language using the
>>> AeroGear API.
>>
>> +1 I like the idea of common docs, with some context switch ability to shift platform. This will not always be possible but I think it could be on many of our features. It might also help point out issues or mis-matches between libraries.
>>
>>>
>>> 4. 1:1 mappings
>>> I'd like to see the iOS, Android and Javscript APIs be self-contained
>>> things that you can just drop in and use, with 1:1 mappings (what you
>>> get on Android for a (sub)project, is what you get on iOS). There could
>>> be technical reasons why these things are split up the way they are now,
>>> let me know if so. I could be totally wrong on this too.
>>
>> As above there is not always a 1:1 mapping.
>>
>>>
>>> Missing pieces:
>>> - Where do we fit in Cordova?
>>
>> As Erik said - Cordova is a another core platform and should be featured.
>>
>>> - AeroGear Auth, Controller?
>>>
>>> These are things I'm not sure yet how they would fit in the proposed scheme.
>>>
>>> I think this is a step in the right direction, and I really hope it is
>>> helpful. Let's iterate on this. Let me know what you think and how we
>>> can improve. Looking forward to hear your opinions on this.
>>
>> Good stuff Hylke, and sorry for the delay getting back to you!
>>
>>>
>>> Thanks,
>>>
>>> Hylke
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>_______________________________________________
>aerogear-dev mailing list
>aerogear-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/aerogear-dev
>

-- 
abstractj