On Wed, Apr 30, 2014 at 4:24 PM, Jeremie BOUSQUET <
[email protected]> wrote:
> Hi,
>
> This is a very complex subject, I read the proposal but it's difficult to
> choose ... Some thoughts below, more than answers. I'm in now way a css
> expert anyway :)
>
> There could be some additional info on extensions repository, telling you
> what is the "favorite skin" of an existing application. Something like
> "Best viewed with Flamingo-style skin". For this example, you would put
> most efforts on the look of the app under flamingo skin, and just minimal
> maintenance on how it looks with colibri (ie, check that functionalities
> are fulfilled, even if display is not optimal). Whatever the solution
> (branch not branch var1 2 3 4 ...), it's always a logical branch in terms
> of maintenance/validation, so it's always a cost for the application owner.
>
> Sometimes the line between pure presentation and "feature" is blurred. For
> example creating items from a pop-up (modal), to me it's not something that
> should depend on the skin. It only depends on your app. And it's already
> possible without bootstrap or flamingo, "bundled in XE" (like, users
> creation form).
> The way you display form fields is pure presentation
> (grid/columns/vertical/horizontal), but it's difficult to anticipate some
> semantic meaning of your fields when you use vertical layout / colibri,
> that would affect how you display them in a grid with bootstrap.
> Going back to your examples in [1], (i) and (ii) screenshots, from the
> bootstrap version I could define that there is a "title" zone (left
> column), an "assignment" zone (left column, over 2 sub-columns), a "status"
> zone (right column), and a "description" zone (below). I would use those
> names as css classes, then assign them a style according to the skin
> (bootstrap grids and whatever I want or nothing in colibri). But this I can
> only define once I migrated to a grid display, from the original view with
> colibri (vertical layout), I think I'd never have though about such
> structure. But putting in place this structure with proper css classes is a
> good thing for my app, whatever the skin. The fact that it won't improve
> the display in colibri is not an issue, at least it will not destroy
> anything. Putting directly the bootstrap "col-*" css classes in my html,
> has no semantics, mixes presentation with source, and has no benefit apart
> realizing a strong dependency to bootstrap which is not good for the
> future.
>
> Another question maybe, will colibri be considered an old skin, or an
> alternative skin ? Usually xwiki team supports only one skin at a time
> (after some kind of deprecation period), but the problem is that skins like
> colibri have a longer life-cycle and are more customized by users than
> older skins used to be (at least, I think).
> Currently in extension repository there are not so much "full" skins
> (custom or standard), there are quite a few colorthemes for colibri though,
> maybe because it's quite easy to create and package a color theme, but it's
> not so easy to create and package a complete xwiki skin. If creating and
> packaging skins gets easier (which is an objective I suppose, and is
> already easier than before), logically there should be more and more custom
> skins available. It would become even more difficult to solve the problem
> of presentation of an application depending on the skin.
>
> It would be interesting to know what real use of colibri skin is made by
> existing applications.
> To explain : in my app (mail archive), I used when I could css classes
> described by the vertical layout standard ("xform", etc). And I started to
> implement using velocity variables for colors coming from the ColorTheme,
> to adapt to the one selected. Apart from that, for the most "customized"
> views (like the topics view with answers), I generated completely custom
> HTML and specific css classes - I do not rely at all on colibri for this,
> except for the colors, because there's nothing fitting my needs in colibri
> (or in extensions I know). For these pages I completely assume skin
> compatibility, but at the same time I have nothing to do, except maybe add
> some mappings with bootstrap classes to improve display, if needed.
>
> All this reminds me of a discussion started by Denis on the same topic [2].
> I tend to share the same view as Denis about this, that having more
> standard ways of producing html in xwiki could help solving nicely most
> issues with skins compatibilities.
> For example $doc.display is nice, but does only a very small part of the
> job it could do IMHO. So I started to write some velocity macros to
> generate form fields from both an XClass field definition, and the
> translation page prefix. Don't know if it's a good way to go, but based on
> some naming rules for fields translations (like, prefix.fieldname.hint,
> prefix.fieldname.label, etc...), if a translation exist or not, I display a
> field with or without xHint, label, etc. I also have a macro that you can
> pass an array of field names and that displays the corresponding form with
> vertical layout. Many things are missing, and the number of arguments of
> those macros is a bit big (but most of them are optional), but it allowed
> me to removed many boilerplate html (or boilerplate (% %) sequences,
> alternatively) from most of my pages with forms. And I like the fact that
> if a translation for a hint is not available in a language, then it's just
> not displayed, and I don't have to code this condition everywhere.
> Regarding my second remark about semantics, what would be missing is some
> macro to create a group of fields (ie a fieldset) with a specific css class
> (as that one can't be generic and depends on your app always and on the
> meaning of the fields). The semantics of fields do not always relate with
> where you display them and how they are grouped, but usually, as a good
> practice, it should.
> Maybe such macros already exist (maybe in AWM), but they're not published
> as a public api (or I'm not aware of it).
>
> To sum up moving to a new skin should not unlock new functionalities in
> your app, or else I think you're relying too much on this new skin. It
> should just unlock new ways of presenting your app UI. I'm more in favor of
> var3 (relying on a standard), as the parts mostly concerned are forms, and
> such a standard already exists for forms. If there's a way to have it
> cleanly adapt for colibri and flaming, and maybe introduce only new rules
> that may be implemented only with flamingo, I think it could work / be
> enough. If the standard is materialized by some sort of xwiki api, and
> applications rely on the standard, and the skins rely on the api, then you
> lower the maintenance activities.
>
I'm also in favor of var3. Junco Skin solves this problem by having a
mapping between the 'standard' and the Bootstrap specific classes, see
https://github.com/evalica/bootswatch/blob/junco-themes/global/xwiki-mapping.less.
But the thing is that we need to have LESS in order to extend and map
the classes (or duplicate the code).
Regarding your comments about the form macros, I agree that this system
might be helpful and we should invest some time in cleaning/creating these
'standard' structure macros.
Thanks for your answer,
Caty
>
> BR,
> Jeremie
>
> [1]
> http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation
> [2] http://markmail.org/message/shd55qxt7w56ypy3
>
>
>
>
>
> 2014-04-16 14:08 GMT+02:00 Ecaterina Moraru (Valica) <[email protected]>:
>
> > Hi,
> >
> > With the new Flamingo skin and with the design investigations done on
> > existing Applications, there are more and more questions related to:
> > * how will the applications be displayed on the new skin, while
> conserving
> > the same look on the old skin;
> > * how much an application should preserve previous functionality and how
> > many efforts are we putting in adapting the functionality for new
> layouts;
> > * when do we create a new application vs. when do we retire one;
> > * etc.
> >
> > This question applies in general to applications and you can also read
> some
> > discussions about applications like Panels [1] or ColorThemes [2].
> >
> > In this thread I want to discuss some variants related to application's
> > presentation:
> >
> >
> http://design.xwiki.org/xwiki/bin/view/Proposal/ApplicationPresentation#HVariants
> >
> > I am interested in our position regarding this topic and if we have like
> a
> > 'standard' solution or if the answer depends on the application in cause.
> >
> > Thanks,
> > Caty
> >
> > [1] http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements
> > [2]
> http://design.xwiki.org/xwiki/bin/view/Proposal/ColorThemeforFlamingo
> > _______________________________________________
> > devs mailing list
> > [email protected]
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
