+1 for B, it seems the most natural one in the end. Thanks -Vincent
On 23 Apr 2014 at 17:37:04, Guillaume Louis-Marie Delhumeau ([email protected](mailto:[email protected])) wrote: > Hi. > > Your arguments make sense. Actually, we had other options in mind: > http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar#HImplementationConsiderationsabouttheBaritself > > It seems, regarding your answers, that the variation B is better than the > current proposal. > > The variation B consists on developing only one panel which is the > "AppBar", or more certainly the "Favorite Applications Panel" + an admin UI > to configure it instead of using the panel wizard. > > We still need to add an option about the size of the panels bars, but we do > not need a panel per application anymore. > > If we all agree on this, I will start the implementation. > > Thanks for your help, > Guillaume > > > > 2014-04-16 18:14 GMT+02:00 Jeremie BOUSQUET : > > > 2014-04-16 17:02 GMT+02:00 Marius Dumitru Florea < > > [email protected]>: > > > > > On Wed, Apr 16, 2014 at 5:05 PM, Jeremie BOUSQUET > > > wrote: > > > > Hi, > > > > > > > > Just some thoughts reading this ... > > > > > > > > > > > > 2014-04-16 14:48 GMT+02:00 [email protected] : > > > > > > > >> Hi Marius, > > > >> > > > >> On 16 Apr 2014 at 13:11:34, Marius Dumitru Florea ( > > > >> [email protected](mailto:[email protected] > > )) > > > >> wrote: > > > >> > > > >> > On Tue, Apr 15, 2014 at 4:54 PM, [email protected] wrote: > > > >> > > Hi Marius, > > > >> > > > > > >> > > On 10 Apr 2014 at 21:07:13, Marius Dumitru Florea ( > > > >> [email protected](mailto:[email protected] > > )) > > > >> wrote: > > > >> > > > > > >> > >> On Thu, Apr 10, 2014 at 6:08 PM, Guillaume "Louis-Marie" > > Delhumeau > > > >> > >> wrote: > > > >> > >> > > > >> > >> > But developers already needs to create a UI Extension, why not > > a > > > >> panel? > > > >> > >> > > > >> > >> Because for the panel you'd have to write code.. Moreover, we > > > >> > >> discussed about the fact that the non-typed parameters of the UI > > > >> > >> Extension are not always a good idea and that for the application > > > >> > >> panel a dedicated class would have been better (with typed > > > >> > >> properties). There is a big difference between having: > > > >> > >> > > > >> > >> icon: myIcon.png > > > >> > >> > > > >> > >> and > > > >> > >> > > > >> > >> content: > > > >> > >> #if ($panelWidth == "small") > > > >> > >> [[image:myIcon.png]] > > > >> > >> #else > > > >> > >> ## Display stuff as a list > > > >> > >> #end > > > >> > >> > > > >> > >> The first is semantic (data) and can be reused in other places. > > The > > > >> > >> second would have to take the image from a property in order to > > not > > > >> > >> duplicate the application icon, so more code.. The first is clear > > > to > > > >> > >> the developer: he has to specify the application icon. The second > > > is > > > >> > >> not, without reading documentation about what to write in the > > panel > > > >> > >> content in order to have the application icon available for the > > > >> > >> application bar. > > > >> > >> > > > >> > >> > Maybe we should provide a template for this kind of panels so > > it > > > >> would be > > > >> > >> > very easy to create a new one, or a wizard that generates it > > > easily? > > > >> > >> > > > >> > >> I find it awkward to ask the dev to create a panel in order to > > > display > > > >> > >> an icon on the application bar. > > > >> > > > > > >> > > It would be awkward if that was the goal but it’s not :) > > > >> > > > > > >> > > > > >> > > There’s no notion of AppBar! > > > >> > > > > >> > Think as a user, you always ask me to do so :). > > > >> > > > >> hehe ;) > > > >> > > > >> > A user that sees the > > > >> > flamingo skin for the first time will notice a vertical bar on the > > > >> > left side that has icons on it, most of which seem to correspond to > > > >> > applications (features). He will never think those are panels! The > > > >> > fact that the left thin vertical bar (to not call it AppBar) is a > > > >> > panel bar is just an implementation detail for me. > > > >> > > > >> In this case you’re saying that implementing the AppBar as several > > > panels > > > >> is bad idea (i.e. it’s not natural) and the AppBar should be a single > > > Panel. > > > >> > > > >> For me either you agree about having each app provide a panel or you > > > don’t > > > >> agree about having apps provide their panels. Agreeing about having > > one > > > >> panel per app and then trying to autogenerate the panels seem too > > much a > > > >> tweak/hack to me and smell of a bad design. > > > >> > > > >> > > It just means that if an app wants to have a panel on the side, it > > > >> needs to define it as they have always done (see blog app for ex) :) > > > >> > > > > >> > We're talking about the left side, the thin vertical bar. The app > > will > > > >> > want to put an icon on it, not a panel. A panel is just the means by > > > >> > which the app is going to make the icon available for the user. > > > >> > > > >> The thin bar can be anywhere, on the left, on the right, for any kind > > of > > > >> panel. The idea is to still call Panels the panel technology. We’re > > just > > > >> adding panel sizes. > > > >> > > > >> Again if you don’t agree about having panels provided by apps then we > > > need > > > >> to materialize the AppBar by having it as a specific Panel (and thus > > > have a > > > >> custom UI to configure that AppBar). > > > >> > > > >> > > So if an App wants that its users to display a panel to link to > > > them, > > > >> then they do the users a favour by creating such a panel for the users > > > to > > > >> use. > > > >> > > > > >> > Again, the App doesn't want "to display a panel”. > > > >> > > > >> The app doesn’t want to display anything. It provides panels for users > > > who > > > >> use to use them to be able to do so. They can provide a shortcut panel > > > if > > > >> they wish. If you don’t agree with this (which is fine) then shortcuts > > > >> should not be implemented as panels IMO and instead we should have an > > > >> AppBar panel. > > > >> > > > >> > The App wants to > > > >> > allow the users to have a shortcut. In flamingo we display app > > > >> > shortcuts on the left side. > > > >> > > > >> Not quite. App shortcuts can be anywhere: on the left, on the right, > > in > > > 2 > > > >> columns or in 1 column. It just happens that by default we’ll position > > > them > > > >> on the left in one column. > > > >> > > > >> > So apps will want to have their shortcuts > > > >> > displayed on the left side. If what it takes to display a shortcut > > on > > > >> > the left side is to create a panel then the App will provide a > > panel, > > > >> > but we should make app devs a favor by simplifying this as mush as > > > >> > possible (eliminating the need of creating the panel and > > copy-pasting > > > >> > code is possible). > > > >> > > > >> Well you’re making a good point that Panels may not be the most > > natural > > > >> way to represent an app shortcut. I think I agree that it would be > > more > > > >> natural to have an AppBar Panel (that can be configured with a > > specific > > > UI > > > >> to decide what apps it should display - Personally I’d prefer calling > > it > > > >> Favorite Applications Panel and keep the existing Applications Panel > > to > > > >> list all apps). > > > >> > > > > > > > > Both could be just variants of the same Panel adjusting to the width of > > > the > > > > panel left/right area, what do you think ? > > > > Ie, with a "large" panel width, you would display what is in > > > "Applications > > > > Panel", with a "thin" panel width, you would display what would be in > > > > "Favorite Applications Panel". > > > > I mean, the current "applications panel" could allow end-users to > > choose > > > > their "favorite apps", and group the rest in the "..." or "other apps" > > > > shortcut (which it currently does except it doesn't use the wording > > > > "favorite"). Basically both represent a list of links to applications > > > > available in 1-click, along with a list of other applications available > > > in > > > > 2-clicks, both available from any page (panel concept). > > > > Another example: if this "thin panel column" / "AppBar" is a set of > > > > specific (distinct) Panels that you can order as you want with panel > > > > wizard, it means you can put some other completely unrelated Panels in > > > > between those applications panels (like a stats panel, a toc panel, > > ...). > > > > > > > Nice and flexible, but does it mean anything in terms of UI ? Would you > > > > ever want to do that ? I'm not sure ... > > > > > > Good point. Indeed I'm starting to think that having a Favorite > > > Applications Panel to handle the app icons is better than having a > > > panel for each icon. > > > > > > > > > > > > > > >> > > > >> > > Autogenerating panel would make this a special case and I’m not > > sure > > > >> we need a special case here. > > > >> > > > > >> > While discussing with Guillaume in private, I end up realising that > > > >> > what we are missing is the ability to 'configure' the panels. Right > > > >> > now you can add a panel only once (and even if you add it twice it's > > > >> > going to display the same thing). But what if I create a generic > > > >> > panel, that has some parameters, and I would like to add this panel > > > >> > twice, with different values for the parameters. I can't. But if you > > > >> > think, you can do this with wiki macros. I can call the same macro > > > >> > with different parameters in the document content. Moreover, most of > > > >> > the current panels are not easily reusable, for instance if I want > > to > > > >> > display the same thing inside the document content or in a dashboard > > > >> > widget I have to either copy the panel content or write some > > Velocity > > > >> > code. For the future I think we should investigate implementing > > panels > > > >> > as wiki macros. With this, we can use directly the wiki macro that > > > >> > Guillaume is going to use right now in a panel. > > > >> > > > >> So you mean removing PanelClass/Sheet/Template (i.e. remove the notion > > > of > > > >> panels or have it only mean the left and right areas) and instead when > > > >> someone wants to write a panel they need to write a wiki macro? Thus > > in > > > the > > > >> left and rights areas, you’d configure the list of macros to use with > > > their > > > >> parameters, similar to the {{gallery}} macro for images? > > > >> > > > >> This means we wouldn’t be able to list panels anymore, except by > > having > > > a > > > >> “Panel” category for all macros representing panels. > > > >> > > > >> Or do you mean having a {{panel}} macro that bridges PanelClass > > xobjects > > > >> and macros: > > > >> - keep PanelClass and pages having PanelClass xobjets as now > > > >> - {{panel reference=“Panels.Applications”/}} > > > >> - {{panel reference=“MySpace.MyPanelPage” > > > parameters=“param1=value1,…"/}} > > > >> - change the way we define the panels to display on the left/right > > areas > > > >> by using this {{panel}} macro. For example by having a > > Left/RightPanels > > > >> page. > > > >> > > > >> ? > > > >> > > > > > > > > > > > Is it really a problem of panels architecture, or merely a problem of > > > some > > > > lack of macros ? > > > > > > My "problem" was that we have two notions "panels" and "macros" and I > > > thought that we can implement panels using macros. But we can't > > > because we cannot set rights on macro calls (a panel would be a macro > > > call in a left/right side area). > > > > > > > If you want to put same content in 2 panels, or in a panel and a > > > dashboard > > > > gadget, to me it means that you miss a rendering macro because you > > should > > > > never duplicate your code. > > > > > > Yes, this is the solution. > > > > > > > I suppose in most cases with this principle, you would never write any > > > > content in a Panel except a call to a macro with some parameters, > > > because I > > > > think you can almost always find a use-case where it'd be interesting > > to > > > > put any panel content in a dashboard gadget or somewhere else. > > > > But I suppose also it was not like that because initially (maybe still) > > > the > > > > idea was more to be able to include a Panel everywhere you want (like > > for > > > > Statistics for example). But being able to include a content through a > > > > rendering macro wherever you want (in a Panel, in a gadget, inline in a > > > > page) seem more flexible. > > > > > > Yes, but you cannot set rights unless you bind the macro call to a > > > document. > > > > > > > Well you would set rights at the level of the container of the macro, so at > > page level (a page that could contain a Panel, dashboard gadgets, or just > > be a "plain" page), which anyway until now represent the finest level you > > can set access rights on (until you add access rights to objects or macro > > calls ;) ). A dashboard gadget is just something that wraps a macro call > > with additional layout info (column/row), I imagine a panel could be seen > > the same way. But you can also write any specific content in a dashboard > > gadget (some groovy script, some velocity script, several macro calls...) - > > and it's the same for a Panel. It's just an UI thing with a content and > > some layout specificity / configurations. > > To go back to initial subject (sorry), I'd say that improving panels > > technology by adding the "size" parameter is very nice, the rest falls back > > more into "improving existing panels" (not just technology). > > Another example (that is listed in the proposal btw), if you implement this > > "AppBar" as a set of Panels containing App name + Large Icon, then if one > > day you improve Panels technology so you can display a horizontal panel bar > > and not just vertical, and you want to implement something very similar to > > the nice "dock" of MacOS, you would have to rewrite all apps panels or > > create new ones (containing large icon without app name), and rewrite your > > panel technology to be able to zoom a panel (and move the others further) > > when hovered - and eventually add a specific typing of Panels so you > > activate this behaviour only for those who represent apps panels. > > While if you implement the "AppBar" as a unique Panel there is no impact on > > panel technology by itself, to implement any variation of AppBar - and the > > only inputs you need are "the info from app descriptors" whatever it could > > be. > > > > > > > > > > Thanks, > > > Marius > > > > > > > > > > > > > > >> > > > >> Thanks > > > >> -Vincent > > > >> > > > >> > Thanks, > > > >> > Marius > > > >> > > > > >> > > > > > >> > > Thanks > > > >> > > -Vincent > > > >> > > > > > >> > >> The dev should just fill an > > > >> > >> application descriptor and then the App Bar manager (panel wizard > > > or > > > >> > >> whatever) should create a panel on the fly (if that is needed for > > > the > > > >> > >> underlying implementation) to display the icon/shortcut on the > > > >> > >> application bar. > > > >> > >> > > > >> > >> Thanks, > > > >> > >> Marius > > > >> > >> > > > >> > >> > > > > >> > >> > > > > >> > >> > 2014-04-10 16:09 GMT+02:00 Marius Dumitru Florea < > > > >> > >> > [email protected]>: > > > >> > >> > > > > >> > >> >> To be clear, I'm not against reusing the left panels bar for > > the > > > >> app > > > >> > >> >> bar. What I don't like is asking application developers to > > > write a > > > >> > >> >> panel (boilerplate code) in order to have their application > > > listed > > > >> > >> >> somewhere. > > > >> > >> >> > > > >> > >> >> Thanks, > > > >> > >> >> Marius > > > >> > >> >> > > > >> > >> >> On Thu, Apr 10, 2014 at 4:41 PM, Marius Dumitru Florea > > > >> > >> >> wrote: > > > >> > >> >> > I don't like it very much. Instead of writing code like > > this: > > > >> > >> >> > > > > >> > >> >> > #if ($panelWidth == "small") > > > >> > >> >> > ## Display stuff as icons > > > >> > >> >> > #else > > > >> > >> >> > ## Display stuff as a list > > > >> > >> >> > #end > > > >> > >> >> > > > > >> > >> >> > in a panel, I would prefer to describe my application using > > an > > > >> XClass > > > >> > >> >> > (with properties for app name and icon). Then the system > > > (XWiki, > > > >> Panel > > > >> > >> >> > Wizard, whatever) should use these data (app name and icon) > > to > > > >> build > > > >> > >> >> > and UI that lets the user put shortcuts to his favourite app > > > to > > > >> a bar. > > > >> > >> >> > If you want, the system should create this "panel". Asking > > app > > > >> > >> >> > developers to write this boilerplate code to have their app > > > >> listed is > > > >> > >> >> > not nice. > > > >> > >> >> > > > > >> > >> >> > Thanks, > > > >> > >> >> > Marius > > > >> > >> >> > > > > >> > >> >> > On Thu, Apr 10, 2014 at 4:17 PM, Guillaume "Louis-Marie" > > > >> Delhumeau > > > >> > >> >> > wrote: > > > >> > >> >> >> Hi. > > > >> > >> >> >> > > > >> > >> >> >> After some discussions with Caty and Vincent, we would like > > > to > > > >> propose > > > >> > >> >> you > > > >> > >> >> >> new ideas about the panels technology, that replaces our > > > >> previous > > > >> > >> >> >> propositions about the Flamingo Applications Bar. > > > >> > >> >> >> > > > >> > >> >> >> The proposal is there, with more explanations and > > > screenshots: > > > >> > >> >> >> > > > >> http://design.xwiki.org/xwiki/bin/view/Proposal/PanelsImprovements > > > >> > >> >> >> > > > >> > >> >> >> Here is my +1. > > > >> > >> >> >> > > > >> > >> >> >> Louis-Marie _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
