[xwiki-devs] [Proposal] Improve our Panels technology
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
Hi, So this proposal is about implementing the 'AppBar' by using PanelClass objects to represent AppBar entries (it was Var C from the initial proposal http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar#HVarC ). 'AppBar' will not be a new functionality, but it will be the 'LeftPanels' column using 'small width' panels (the panel's width is a new concept). Applications developers should provide a 'small width' panel for their application in order to be added to the LeftPanels column. I think this solution is easier integrable with what we currently have (Panel Wizard) and the users will have a consistent way of customizing the panels. My +1 Thanks, Caty On Thu, Apr 10, 2014 at 4:17 PM, Guillaume "Louis-Marie" Delhumeau < [email protected]> 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
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 <[email protected]> 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
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 <[email protected]> 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 <[email protected]> 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
But developers already needs to create a UI Extension, why not a panel? 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? 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 <[email protected]> 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 <[email protected]> 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Thu, Apr 10, 2014 at 6:08 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> 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. 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 <[email protected]> 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 <[email protected]> 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
So you are not opposed to the panel improvements we have proposed, but you don't want users to create a panel per application, by themselves. [Brainstorm] If we agree on the idea that the application icons should be implemented with panels, maybe we can add different kinds of panels: A - the normal panels: what we already have B - auto-generated "virtual" panels. For these (B), we can propose in the panel wizard some panels that do not really exists, but that are generated upon app descriptors. Other idea: a document listener that generates the appropriate application panel every time the app descriptor is changed. In the two cases, we need to define what a descriptor is. Caty is writing a proposal about it and we will post it here when it is ready. What do you think? Thanks, Louis-Marie 2014-04-10 21:06 GMT+02:00 Marius Dumitru Florea < [email protected]>:
On Thu, Apr 10, 2014 at 6:08 PM, Guillaume "Louis-Marie" Delhumeau <[email protected]> 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. 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 <[email protected]> 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 <[email protected]> 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
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
On 14 Apr 2014 at 18:27:50, Guillaume Louis-Marie Delhumeau ([email protected](mailto:[email protected])) wrote:
So you are not opposed to the panel improvements we have proposed, but you don't want users to create a panel per application, by themselves.
[Brainstorm] If we agree on the idea that the application icons should be implemented with panels, maybe we can add different kinds of panels:
A - the normal panels: what we already have B - auto-generated "virtual" panels.
For these (B), we can propose in the panel wizard some panels that do not really exists, but that are generated upon app descriptors.
Other idea: a document listener that generates the appropriate application panel every time the app descriptor is changed.
In the two cases, we need to define what a descriptor is. Caty is writing a proposal about it and we will post it here when it is ready.
What do you think?
If we want to go that way we could define the notion of Panels at the java level as components and then have wiki components for implementing Panels as wiki pages. This allows generating and registering panels dynamically easily. Then have some java code that listen to UIX for “platform.panels.leftPanels” and “platform.panels.rightPanels” extension ids (in the future for some XObject) and register new Panel impls agains the CM. But that’s a bit of work… Thanks -Vincent
Thanks, Louis-Marie
2014-04-10 21:06 GMT+02:00 Marius Dumitru Florea < [email protected]>:
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. 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
FYI, I am going to start the implementation of the first proposal, for 6.1. - In order to help developers to create their application panel, I will create a wiki macro so they just have to call it. - In the future, we will investigate a way to have customizable panels (like we have for dashboard gadgets and wiki macros). - The Panel Wizard should be improved too to make it easy for users to understand that they should use it to add their favourite applications in the left bar. - I will remove the left panel configuration of the Blog Application to fit with Flamingo. Thanks, Louis-Marie. 2014-04-15 16:01 GMT+02:00 [email protected] <[email protected]>:
On 14 Apr 2014 at 18:27:50, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:
So you are not opposed to the panel improvements we have proposed, but you don't want users to create a panel per application, by themselves.
[Brainstorm] If we agree on the idea that the application icons should be implemented with panels, maybe we can add different kinds of panels:
A - the normal panels: what we already have B - auto-generated "virtual" panels.
For these (B), we can propose in the panel wizard some panels that do not really exists, but that are generated upon app descriptors.
Other idea: a document listener that generates the appropriate application panel every time the app descriptor is changed.
In the two cases, we need to define what a descriptor is. Caty is writing a proposal about it and we will post it here when it is ready.
What do you think?
If we want to go that way we could define the notion of Panels at the java level as components and then have wiki components for implementing Panels as wiki pages. This allows generating and registering panels dynamically easily. Then have some java code that listen to UIX for “platform.panels.leftPanels” and “platform.panels.rightPanels” extension ids (in the future for some XObject) and register new Panel impls agains the CM.
But that’s a bit of work…
Thanks -Vincent
Thanks, Louis-Marie
2014-04-10 21:06 GMT+02:00 Marius Dumitru Florea < [email protected]>:
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. 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
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! 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) :) 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. Autogenerating panel would make this a special case and I’m not sure we need a special case here. 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
On Tue, Apr 15, 2014 at 4:54 PM, [email protected] <[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 :). 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.
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.
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 wants to allow the users to have a shortcut. In flamingo we display app shortcuts on the left side. 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).
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. 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
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).
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. ? 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
Hi, Just some thoughts reading this ... 2014-04-16 14:48 GMT+02:00 [email protected] <[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 ...
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 ? 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. 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.
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
On Wed, Apr 16, 2014 at 5:05 PM, Jeremie BOUSQUET <[email protected]> wrote:
Hi,
Just some thoughts reading this ...
2014-04-16 14:48 GMT+02:00 [email protected] <[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. 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
2014-04-16 17:02 GMT+02:00 Marius Dumitru Florea < [email protected]>:
On Wed, Apr 16, 2014 at 5:05 PM, Jeremie BOUSQUET <[email protected]> wrote:
Hi,
Just some thoughts reading this ...
2014-04-16 14:48 GMT+02:00 [email protected] <[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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi. Your arguments make sense. Actually, we had other options in mind: http://design.xwiki.org/xwiki/bin/view/Proposal/AppBar#HImplementationConsid... 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 <[email protected]>:
2014-04-16 17:02 GMT+02:00 Marius Dumitru Florea < [email protected]>:
On Wed, Apr 16, 2014 at 5:05 PM, Jeremie BOUSQUET <[email protected]> wrote:
Hi,
Just some thoughts reading this ...
2014-04-16 14:48 GMT+02:00 [email protected] <[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
_______________________________________________ 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
+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#HImplementationConsid...
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
On Wed, Apr 23, 2014 at 6:40 PM, [email protected] <[email protected]> wrote:
+1 for B, it seems the most natural one in the end.
+1 as well. Thanks, Marius
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#HImplementationConsid...
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
Agreed, +1 for B. On Wed, Apr 23, 2014 at 6:10 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 23, 2014 at 6:40 PM, [email protected] <[email protected]> wrote:
+1 for B, it seems the most natural one in the end.
+1 as well.
Thanks, Marius
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#HImplementationConsid...
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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
I have committed on master this afternoon a first step, it is now possible to select the width of each panel column (in the panel wizard and in the page elements section of the administration). It works with both Flamingo & Colibri. Guillaume 2014-04-24 14:00 GMT+02:00 Denis Gervalle <[email protected]>:
Agreed, +1 for B.
On Wed, Apr 23, 2014 at 6:10 PM, Marius Dumitru Florea < [email protected]> wrote:
On Wed, Apr 23, 2014 at 6:40 PM, [email protected] <[email protected]> wrote:
+1 for B, it seems the most natural one in the end.
+1 as well.
Thanks, Marius
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#HImplementationConsid...
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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Wed, Apr 16, 2014 at 3:48 PM, [email protected] <[email protected]> wrote:
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).
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.
We wouldn't need a "Panel" category. Any macro can be displayed in a panel (i.e. on the left/right side). Not all will look good of course.
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.
After more thinking I realised that we cannot remove PanelClass/Sheet/Template because we need to be able to set rights on panel documents, i.e. we need to use a separate document for each panel, not just wiki macros called in a left/right side area (document). I think I diverged too much from the topic :)
?
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
participants (6)
-
Denis Gervalle -
Ecaterina Moraru (Valica) -
Guillaume "Louis-Marie" Delhumeau -
Jeremie BOUSQUET -
Marius Dumitru Florea -
vincent＠massol.net