Re: [xwiki-devs] [Proposal] Improve our Panels technology

Hi. Your arguments make sense. Actually, we had other options in mind: http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar#HImplementationConsi… 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 < > mariusdumitru.florea(a)xwiki.com&gt;gt;: > > > 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 vincent(a)massol.net : > > > > > >> Hi Marius, > > >> > > >> On 16 Apr 2014 at 13:11:34, Marius Dumitru Florea ( > > >> mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com > )) > > >> wrote: > > >> > > >> > On Tue, Apr 15, 2014 at 4:54 PM, vincent(a)massol.net wrote: > > >> > > Hi Marius, > > >> > > > > >> > > On 10 Apr 2014 at 21:07:13, Marius Dumitru Florea ( > > >> mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com > )) > > >> 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 < > > >> > >> > mariusdumitru.florea(a)xwiki.com&gt;gt;: > > >> > >> > > > >> > >> >> 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