Conductor UI - some ideas for a better conductor

Andrew Fitzsimon afitzsim at redhat.com
Wed Feb 8 11:47:31 UTC 2012


>> 
> 
> Hey,
> 
> I have read thorugh your ideas and I must say it looks really impressive.
> 
> I'd like to point out a few things. For a developer the most important thing is to have a strict guide how to use certain website elements and blocks. Strictly given structure of application elements are really important to keep application layout consistent. So we should have given library of "small" elements (buttons, pagination, headers, lists, tables...) and "layout level structures" like content sections, tab-containers... With these, abiding the haml structure is as important as actual styling of the elements. Haml structure is the actual thing that everyone of us creates, so there must be strictly given what is the page and elements structure through the app.

So the haml of a view should be constrained to its respective parent.  The view name and the parent #ID of here it exists should be the same to make this easy. On the shell/chrome level the parent haml and sub views are known. Beyond that we get a little tricky with having to check that a view applies to the session or has been requested.

I'm still working on some demo haml to illustrate the higher up haml structure of where our views fit in but if you're online I can ping you with more specific info.
I'll need help with things like how we implement global and per-user caching and weighing up what things are too expensive to do by default.   (hoping to catch Scott sometime this week for a sanity check of ideas)

> 
> The css part is often developed by far less people ( but one person is definitely not enough ), its also important to have a unified style pieces too, which is quite easily maintained by mixins.
> 
As mentioned there will still be style rules allocated to functional components but I understand that we need to document this further for each context.

> Using view anchors (#something) in urls is nice idea which works nice in rails routes by specifiing :anchor (http://lists.rubyonrails.org/pipermail/rails/2006-June/046488.html).
> 
Yes I am aware it was possible :-).  Whole page requests are very very disrespectful of the client if they aren't absolutely needed.. Not doing this with sane caching and ajaxing expensive requests might fix up a lot of our stuff.


> Andy how would you like to strucure the css? I would like to see you opinion on this. I mean how would the actual scss files organize? How would we implement various features in it? The way it is now or some other way?
> 
All sass to be rendered into style.css
This means all views, layout chrome and components are loaded with the initial hit.
There is no reason why our CSS should be so expensive as to make this a problem.

As for the scss file layout,  I imagine it would resemble something like this :

Layout Chrome
Globals (including widgets)
Views-global (user views etc)
Views-monitor
Views-admin
Views-*..... Etc
Media rules

And be rendered in that hierarchy down to style.css

> 
> From my point of view the actual styling is not that important (It can be quite easily changed) but what I find really important is unifiing features and elements structures through the application (haml stuff basicly) which is not so easy to change during the time and can base this work on what we have now. Having library of haml templates of various features would greatly help I think.
> 

I totally understand. I'm putting a draft haml structure together.
the layout/component/views parts are easy, right now I'm still wrangling system global changes and other small things like status notification.


> I would really like to see the structural changes you propose in our app.
> 

Me too :-)  remember, it's going to be a mock-draft but I hope it will be useful

Thanks for your reply!


More information about the aeolus-devel mailing list