Plone

On 29/08/2012, at 2:01 PM, Nathan Van Gheem wrote:

> Hi All,
>
> Eric has asked me to head up the UI team and all things improving  
> Plone's UI.
>
> Plone's user interface is starting to show it's age. Initially, the  
> main objective of the UI revamp effort will be to improve existing  
> UI failures and provide a framework to a better UI future.
>
> To tackle this, we'll focus on these things:
>
> 1) Provide obvious fixes and improvements to plone's existing UI  
> failures
> 2) Provide guidelines to developers in user testing new UI. The work  
> that martin and the developers at UCLA did is valuable in this  
> respect.
> 3) Make decisions and implement new widgets, js libraries and  
> testing infrastructure.
>
> One thing I'm not going to currently address is future deco related  
> UI concerns. That project is still cutting edge and we're not going  
> to concern too much of this effort, with the deco development. That  
> being said, deco development should adhere to decent UI guidelines  
> and many UI savvy people will be at the coming Sea Sprint.
>
> With all the said, I went through most of plone's UI and have  
> identified these issues:
>
> - content rules
>   - Confusing UI and too many page loads. Various areas this can be  
> improved.
> - folder contents
>   - drag and drop rarely works and pisses many users off, no easy  
> way to move items in a large folder. I ended up writing  
> wildcard.foldercontents to address some of these issues. If we can  
> integrate this or something similar, I think it'd be a big help.
> - widgets
>   - keyword/tag widget
>     - even the new one isn't very good. I like eea.tags or using the  
> chosen widget(
>   - date/time
>   - in and out widget
>     - one of the biggest widget failures. This could also be a  
> chosen widget. Some work to this has been played around with on  
> plone.app.widgets
>   - creators/contributors widget
>     - should be able to choose actual users, maybe display this info  
> somewhere on the content in a viewlet
> - Control panel
>   - could use better organization
> - users/groups control panel
>   - maybe use http://datatables.net/ or http://www.flexigrid.info/
> - html filtering
>   - terrible widgets here again...
> - types
>   - not bad but could use a bit of love
> - workflow manager
>   - plip'd for 4.3 but needs testing
>
>
> What I'm going to do now is choose items that I feel are most  
> important and start creating wireframes for them. People can comment  
> on them and suggest changes. Then I'd like to see people step up and  
> implement some of the changes as I will also be trying to do.
>
> Now, a few questions to the community.
>
> 1) What else needs help?

I'd like to add guidelines for where to put add in functionality from  
plugins. For example, if I write a plugin, there seems to be somewhat  
random places functionality turns up. In eea.facetednavigation you  
enable it via a folders action menu which is weird, and then you get a  
extra document tab to edit the settings. Lineage you use the the sub- 
type menu to enable lineage. I think perhaps there needs to some  
thought into the kinds of ways 3rd party plugins seem to want to  
integrate into plone and plone could be changed to make those appear  
in an obvious way. I'm hoping that plone.app.toolbar and deco will  
solve some of these issues.


> 2) Who is interested in helping?
> 3) Where do we house the documentation for UI testing and  
> guidelines? David Glick suggested we just use the buildout docs: http://buildoutcoredev.readthedocs.org/en/latest/



>
>
>
> -Nathan
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.  
> Discussions
> will include endpoint security, mobile security and the latest in  
> malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers

Am 29.08.2012 06:01, schrieb Nathan Van Gheem:
> Hi All,
>
> Eric has asked me to head up the UI team and all things improving
> Plone's UI.
>
> Plone's user interface is starting to show it's age. Initially, the main
> objective of the UI revamp effort will be to improve existing UI
> failures and provide a framework to a better UI future.
>
> To tackle this, we'll focus on these things:
>
> 1) Provide obvious fixes and improvements to plone's existing UI failures
> 2) Provide guidelines to developers in user testing new UI. The work
> that martin and the developers at UCLA did is valuable in this respect.
> 3) Make decisions and implement new widgets, js libraries and
> testing infrastructure.
>
> One thing I'm not going to currently address is future deco related UI
> concerns. That project is still cutting edge and we're not going to
> concern too much of this effort, with the deco development. That being
> said, deco development should adhere to decent UI guidelines and many UI
> savvy people will be at the coming Sea Sprint.
>
> With all the said, I went through most of plone's UI and have identified
> these issues:
>
> - content rules
>    - Confusing UI and too many page loads. Various areas this can be
> improved.
> - folder contents
>    - drag and drop rarely works and pisses many users off, no easy way
> to move items in a large folder. I ended up
> writing wildcard.foldercontents to address some of these issues. If we
> can integrate this or something similar, I think it'd be a big help.
> - widgets
>    - keyword/tag widget
>      - even the new one isn't very good. I like eea.tags or using the
> chosen widget(
>    - date/time
>    - in and out widget
>      - one of the biggest widget failures. This could also be a chosen
> widget. Some work to this has been played around with on plone.app.widgets
>    - creators/contributors widget
>      - should be able to choose actual users, maybe display this info
> somewhere on the content in a viewlet
> - Control panel
>    - could use better organization
> - users/groups control panel
>    - maybe use http://datatables.net/ or http://www.flexigrid.info/
> - html filtering

I'm currently working on moving the control panel to 
z3c.form/plone.app.registry: https://dev.plone.org/ticket/10359

When I'm done with this, I'm happy to implement UI-improvements for the 
control panel, if someone steps up to do the UI concept and wireframing.

Cheers,
timo

HI,

On 29 August 2012 05:01, Nathan Van Gheem <vangheem@...> wrote:

> Hi All,
>
> Eric has asked me to head up the UI team and all things improving Plone's
> UI.
>

+100 mega awesomeness, Batman.


> Plone's user interface is starting to show it's age. Initially, the main
> objective of the UI revamp effort will be to improve existing UI failures
> and provide a framework to a better UI future.


Cool!


> To tackle this, we'll focus on these things:
>
> 1) Provide obvious fixes and improvements to plone's existing UI failures
> 2) Provide guidelines to developers in user testing new UI. The work that
> martin and the developers at UCLA did is valuable in this respect.
> 3) Make decisions and implement new widgets, js libraries and
> testing infrastructure.
>
> One thing I'm not going to currently address is future deco related UI
> concerns.
>

What about the plone.app.cmsui effort? I felt that actually made some
important strides, not the least of which is making Diazo theming a lot
easier (and breaking the editing UI a lot harder). Personally, I feel
that's an effort worth pushing through even if the overlays are virtually
identical to the respective bits of UI today initially. It's also separate
from Deco.


> That project is still cutting edge and we're not going to concern too much
> of this effort, with the deco development. That being said, deco
> development should adhere to decent UI guidelines and many UI savvy people
> will be at the coming Sea Sprint.
>
> With all the said, I went through most of plone's UI and have identified
> these issues:
>
> - content rules
>   - Confusing UI and too many page loads. Various areas this can be
> improved.
> - folder contents
>   - drag and drop rarely works and pisses many users off, no easy way to
> move items in a large folder. I ended up writing wildcard.foldercontents to
> address some of these issues. If we can integrate this or something
> similar, I think it'd be a big help.
> - widgets
>   - keyword/tag widget
>     - even the new one isn't very good. I like eea.tags or using the
> chosen widget(
>   - date/time
>   - in and out widget
>     - one of the biggest widget failures. This could also be a chosen
> widget. Some work to this has been played around with on plone.app.widgets
>   - creators/contributors widget
>     - should be able to choose actual users, maybe display this info
> somewhere on the content in a viewlet
> - Control panel
>   - could use better organization
> - users/groups control panel
>   - maybe use http://datatables.net/ or http://www.flexigrid.info/
> - html filtering
>   - terrible widgets here again...
> - types
>   - not bad but could use a bit of love
> - workflow manager
>   - plip'd for 4.3 but needs testing
>

Probably worth thinking about the Dexterity TTW editor as well, if you
didn't look at it yet.


> What I'm going to do now is choose items that I feel are most important
> and start creating wireframes for them. People can comment on them and
> suggest changes. Then I'd like to see people step up and implement some of
> the changes as I will also be trying to do.
>

I think that's a great approach! I'd also see if we can entice the UCLA
guys and other non-coder UI people to test/review/suggest improvements.
Outside perspectives are important!


> Now, a few questions to the community.
>
> 1) What else needs help?
>

Some thoughts above.


> 2) Who is interested in helping?
>

Me. ;)


> 3) Where do we house the documentation for UI testing and guidelines?
> David Glick suggested we just use the buildout docs:
> http://buildoutcoredev.readthedocs.org/en/latest/
>

I don't think it overly matters, although I'm not sure why we wouldn't use
plone.org.

Martin

On 29/08/2012, at 4:52 PM, Martin Aspeli wrote:

>> One thing I'm not going to currently address is future deco related  
>> UI concerns.
>
>
> What about the plone.app.cmsui effort? I felt that actually made  
> some important strides, not the least of which is making Diazo  
> theming a lot easier (and breaking the editing UI a lot harder).  
> Personally, I feel that's an effort worth pushing through even if  
> the overlays are virtually identical to the respective bits of UI  
> today initially. It's also separate from Deco.

+1. Although I think it's easier to think about cmsui as two different  
efforts.

plone.app.toolbar which is roughly the same UI elements as exist today  
but all at the top of the screen. The only big difference is that  
overlays are used for everything including editing.That works now but  
is buggy. If someone PLIPed that and got it into 4.3.... added to the  
theming editor plone.app.toolbar would make life so much easier for  
themers.

plone.app.cmsui is all the new UI ideas to improve plone.app.toolbar  
(outside of deco). The downside is some of the suggested changes  
weren't very backwards compatible with 3rd party plugins. But there  
were many great ideas there. Perhaps if they were brought in one by  
one those UI changes would be easier to manage?

On 29/08/2012, at 5:27 PM, Tom Cameron wrote:

> We are starting to regularly implement BootstrapCSS over Plone,  
> particularly for Intranet style sites, we are finding it very  
> helpful for many of the dynamic elements and dealing with  
> alternative clients such as tablets, phones etc. Im not necessarily  
> saying its the best css framework but I think it would be very  
> valuable to consider some of the main css frameworks and see if  
> there is a good fit somewhere.

+1 for bootstrap. I'll just add that plone.app.toolbar is built on  
bootstrap so with plone.app.toolbar you get bootstrap included in  
plone. Not that much of it is used but it could be more widely used.


>
> Tom
>
> On Wed, Aug 29, 2012 at 5:14 PM, Dylan Jay <djay@...> wrote:
> On 29/08/2012, at 4:52 PM, Martin Aspeli wrote:
>
> >> One thing I'm not going to currently address is future deco related
> >> UI concerns.
> >
> >
> > What about the plone.app.cmsui effort? I felt that actually made
> > some important strides, not the least of which is making Diazo
> > theming a lot easier (and breaking the editing UI a lot harder).
> > Personally, I feel that's an effort worth pushing through even if
> > the overlays are virtually identical to the respective bits of UI
> > today initially. It's also separate from Deco.
>
> +1. Although I think it's easier to think about cmsui as two different
> efforts.
>
> plone.app.toolbar which is roughly the same UI elements as exist today
> but all at the top of the screen. The only big difference is that
> overlays are used for everything including editing.That works now but
> is buggy. If someone PLIPed that and got it into 4.3.... added to the
> theming editor plone.app.toolbar would make life so much easier for
> themers.
>
> plone.app.cmsui is all the new UI ideas to improve plone.app.toolbar
> (outside of deco). The downside is some of the suggested changes
> weren't very backwards compatible with 3rd party plugins. But there
> were many great ideas there. Perhaps if they were brought in one by
> one those UI changes would be easier to manage?
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.  
> Discussions
> will include endpoint security, mobile security and the latest in  
> malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>
>
>
> -- 
> Tom Cameron
> Technical Director
>
> Mooball IT
>
> 13 Rowland Street
> Coorparoo, Brisbane QLD 4151
>
> mob: +61 (4) 1455 3212
> skype: mooballdotcom
> Tel: +61 (7) 3843 0516
> Fax: +61 (7) 3843 2316
> http://www.mooball.com
>
>
>
> RECENT PROJECTS
> http://www.bullsmasters.com.au
> http://www.pancreaticcancer.net.au
> http://www.allanlanger.com.au
> http://www.uonservices.org.au
> http://www.asiapacificforum.net
>
> WHAT'S NEW
>
> - Mooball IT is now an authorised Google Apps Reseller - watch the  
> video
> - Google Apps now has rich text email signatures with images
> - Plone 4 is now here upgrade to get new features and faster page  
> loads.
> - Register and renew your domain at Mooball Domains
>
> WEB AGENCY SPECIALISING IN PLONE DEVELOPMENT AND HOSTING
> Plone CMS | Web Apps | Discount Domains | Web Hosting | Google Apps
>
>
> Email disclaimer
>

On Wed, Aug 29, 2012 at 6:01 AM, Nathan Van Gheem <vangheem@...> wrote:
> 1) What else needs help?

The claim of having keyboard shortcuts should either be made true, or
be removed. :-)

//Lennart

We are starting to regularly implement BootstrapCSS over Plone,
particularly for Intranet style sites, we are finding it very helpful for
many of the dynamic elements and dealing with alternative clients such as
tablets, phones etc. Im not necessarily saying its the best css framework
but I think it would be very valuable to consider some of the main css
frameworks and see if there is a good fit somewhere.

Tom

On Wed, Aug 29, 2012 at 5:14 PM, Dylan Jay <djay@...> wrote:

> On 29/08/2012, at 4:52 PM, Martin Aspeli wrote:
>
> >> One thing I'm not going to currently address is future deco related
> >> UI concerns.
> >
> >
> > What about the plone.app.cmsui effort? I felt that actually made
> > some important strides, not the least of which is making Diazo
> > theming a lot easier (and breaking the editing UI a lot harder).
> > Personally, I feel that's an effort worth pushing through even if
> > the overlays are virtually identical to the respective bits of UI
> > today initially. It's also separate from Deco.
>
> +1. Although I think it's easier to think about cmsui as two different
> efforts.
>
> plone.app.toolbar which is roughly the same UI elements as exist today
> but all at the top of the screen. The only big difference is that
> overlays are used for everything including editing.That works now but
> is buggy. If someone PLIPed that and got it into 4.3.... added to the
> theming editor plone.app.toolbar would make life so much easier for
> themers.
>
> plone.app.cmsui is all the new UI ideas to improve plone.app.toolbar
> (outside of deco). The downside is some of the suggested changes
> weren't very backwards compatible with 3rd party plugins. But there
> were many great ideas there. Perhaps if they were brought in one by
> one those UI changes would be easier to manage?
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>



-- 
*Tom Cameron*
Technical Director

*Mooball IT*

13 Rowland Street
Coorparoo, Brisbane QLD 4151

mob: +61 (4) 1455 3212
skype: mooballdotcom
Tel: +61 (7) 3843 0516
Fax: +61 (7) 3843 2316
http://www.mooball.com

 <http://www.mooball.com/>

*RECENT PROJECTS*
 http://www.bullsmasters.com.au
 http://www.pancreaticcancer.net.au
 http://www.allanlanger.com.au
 http://www.uonservices.org.au
 http://www.asiapacificforum.net

*WHAT'S NEW*

- Mooball IT is now an authorised *Google
Apps*<http://www.google.com/apps/intl/en/business/messaging.html>
Reseller
- *watch the video <http://www.youtube.com/watch?v=9JJDugn4RoQ>*
 <http://www.youtube.com/watch?v=kJT3pagjd8s>*- Google Apps now has rich
text email signatures with images
*
*- Plone 4* is now here upgrade to get new features and faster page loads.
- Register and renew your domain at *Mooball
Domains*<http://domains.mooball.com/>
* *

*WEB AGENCY SPECIALISING IN PLONE DEVELOPMENT AND HOSTING*
Plone CMS | Web Apps | Discount Domains | Web Hosting | Google Apps


Email disclaimer <http://www.mooball.com/email_disclaimer>

I have done some UI experiment to remove search server side for users using
datatables in many screens on a customer project:

* sharing
* users controlpanel for all tabs

The results is a blazing fast user search UI. We have done this on an
intranet with 10K users.

I'm ready to propose a plip to move that code into Plone.  For sure with
100k users We should have a better server side search engine (zcatalog ?)

Regards / Cordialement,
JeanMichel FRANCOIS
Find me on Twitter <http://twitter.com/toutpt> / Retrouvez moi sur
Twitter<http://twitter.com/toutpt_nantes>




2012/8/29 Dylan Jay <djay@...>

> On 29/08/2012, at 4:52 PM, Martin Aspeli wrote:
>
> >> One thing I'm not going to currently address is future deco related
> >> UI concerns.
> >
> >
> > What about the plone.app.cmsui effort? I felt that actually made
> > some important strides, not the least of which is making Diazo
> > theming a lot easier (and breaking the editing UI a lot harder).
> > Personally, I feel that's an effort worth pushing through even if
> > the overlays are virtually identical to the respective bits of UI
> > today initially. It's also separate from Deco.
>
> +1. Although I think it's easier to think about cmsui as two different
> efforts.
>
> plone.app.toolbar which is roughly the same UI elements as exist today
> but all at the top of the screen. The only big difference is that
> overlays are used for everything including editing.That works now but
> is buggy. If someone PLIPed that and got it into 4.3.... added to the
> theming editor plone.app.toolbar would make life so much easier for
> themers.
>
> plone.app.cmsui is all the new UI ideas to improve plone.app.toolbar
> (outside of deco). The downside is some of the suggested changes
> weren't very backwards compatible with 3rd party plugins. But there
> were many great ideas there. Perhaps if they were brought in one by
> one those UI changes would be easier to manage?
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>

On 29 August 2012 08:38, Dylan Jay <djay@...> wrote:

>
> On 29/08/2012, at 5:27 PM, Tom Cameron wrote:
>
>  We are starting to regularly implement BootstrapCSS over Plone,
>> particularly for Intranet style sites, we are finding it very helpful for
>> many of the dynamic elements and dealing with alternative clients such as
>> tablets, phones etc. Im not necessarily saying its the best css framework
>> but I think it would be very valuable to consider some of the main css
>> frameworks and see if there is a good fit somewhere.
>>
>
> +1 for bootstrap. I'll just add that plone.app.toolbar is built on
> bootstrap so with plone.app.toolbar you get bootstrap included in plone.
> Not that much of it is used but it could be more widely used.
>

I think there is merit in trying to use a more fully-featured CSS
framework, mainly because none of us are good enough with CSS to do as good
a job. :) Having well-structured, reusable elements in our CSS is (and has
been) key to making sure add-ons look and work consistently with the rest
of Plone.

I'd love to see us explore p.a.toolbar + bootstrapification of our basic UI
for Plone 5, assuming that comes after 4.3.

Martin

On 2012-8-29 10:24, Jean-Michel FRANCOIS wrote:
> I have done some UI experiment to remove search server side for users
> using datatables in many screens on a customer project:
>
> * sharing
> * users controlpanel for all tabs
>
> The results is a blazing fast user search UI. We have done this on an
> intranet with 10K users.
>
> I'm ready to propose a plip to move that code into Plone.  For sure with
> 100k users We should have a better server side search engine (zcatalog ?)

With 100k users they are likely to be users from an external system 
(Active Directory, LDAP, OpenID, SQL, etc.). You can not index those in 
ZCatalog.

Wichert.

-- 
Wichert Akkerman <wichert@...>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.

On 2012-8-29 11:53, Martin Aspeli wrote:
> I think there is merit in trying to use a more fully-featured CSS
> framework, mainly because none of us are good enough with CSS to do as
> good a job. :) Having well-structured, reusable elements in our CSS is
> (and has been) key to making sure add-ons look and work consistently
> with the rest of Plone.

To put this in a bit of perspective: Plone used to have well-structured 
reusable elements in its HTML & CSS. What killed it though was the 
complete lack of documentation which led to people not using those 
elements or using them incorrectly. And that is where twitter bootstrap 
shines: it is not really that much better than other CSS frameworks, but 
it is very well documented. There is a lesson to be learned here.

Wichert.

-- 
Wichert Akkerman <wichert@...>   It is simple to make things.
http://www.wiggy.net/                  It is hard to make things simple.

On 29 August 2012 10:57, Wichert Akkerman <wichert@...> wrote:

> On 2012-8-29 11:53, Martin Aspeli wrote:
>
>> I think there is merit in trying to use a more fully-featured CSS
>> framework, mainly because none of us are good enough with CSS to do as
>> good a job. :) Having well-structured, reusable elements in our CSS is
>> (and has been) key to making sure add-ons look and work consistently
>> with the rest of Plone.
>>
>
> To put this in a bit of perspective: Plone used to have well-structured
> reusable elements in its HTML & CSS. What killed it though was the complete
> lack of documentation which led to people not using those elements or using
> them incorrectly. And that is where twitter bootstrap shines: it is not
> really that much better than other CSS frameworks, but it is very well
> documented. There is a lesson to be learned here.


+1

Martin

On Aug 29, 2012, at 6:57 AM, Wichert Akkerman wrote:

> On 2012-8-29 11:53, Martin Aspeli wrote:
>> I think there is merit in trying to use a more fully-featured CSS
>> framework, mainly because none of us are good enough with CSS to do as
>> good a job. :) Having well-structured, reusable elements in our CSS is
>> (and has been) key to making sure add-ons look and work consistently
>> with the rest of Plone.
> 
> To put this in a bit of perspective: Plone used to have well-structured 
> reusable elements in its HTML & CSS. What killed it though was the 
> complete lack of documentation which led to people not using those 
> elements or using them incorrectly. And that is where twitter bootstrap 
> shines: it is not really that much better than other CSS frameworks, but 
> it is very well documented. There is a lesson to be learned here.

I remember those days, and I remember having to use !important after every new rule I ever tried to add. That being said, I am jumping out of my seat with the idea of a non-plone community managed style framework and I don't see bootstrap going anywhere in the medium term.

However, to really jump into bootstrap I *think* we should go all or nothing in committing to the change. Piece-mealing isn't going to be worth it and it will be an upgrade disaster. Additionally, we can't expect people to know what is bootstrap and what is plone and what is just random shit floating around. 

That being said, I would be willing to commit a significant effort to this implementation wise - I have lots of experience with bootstrap and have been plone cssing since day 1. Has anything been started on this already? 

Thanks nathan for getting this started! Sign me up on the list of people to help with implementation. I spend a good chunk of time rewriting interfaces on every new project so for me (and future clients!) this is a big win.

Liz

> 
> Wichert.
> 
> -- 
> Wichert Akkerman <wichert@...>   It is simple to make things.
> http://www.wiggy.net/                  It is hard to make things simple.
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers

Thank you everyone for the input. I'll provide some responses.


> Dylan:

I'd like to add guidelines for where to put add in functionality from
> plugins. For example, if I write a plugin, there seems to be somewhat
> random places functionality turns up. In eea.facetednavigation you enable
> it via a folders action menu which is weird, and then you get a extra
> document tab to edit the settings. Lineage you use the the sub-type menu to
> enable lineage. I think perhaps there needs to some thought into the kinds
> of ways 3rd party plugins seem to want to integrate into plone and plone
> could be changed to make those appear in an obvious way. I'm hoping that
> plone.app.toolbar and deco will solve some of these issues.

Agreed



> To tackle this, we'll focus on these things:
>> 1) Provide obvious fixes and improvements to plone's existing UI failures
>> 2) Provide guidelines to developers in user testing new UI. The work that
>> martin and the developers at UCLA did is valuable in this respect.
>> 3) Make decisions and implement new widgets, js libraries and
>> testing infrastructure.
>> One thing I'm not going to currently address is future deco related UI
>> concerns.
>> What about the plone.app.cmsui effort? I felt that actually made some
>> important strides, not the least of which is making Diazo theming a lot
>> easier (and breaking the editing UI a lot harder). Personally, I feel
>> that's an effort worth pushing through even if the overlays are virtually
>> identical to the respective bits of UI today initially. It's also separate
>> from Deco.
>
> Martin, as far as I understand, cmsui is going to be merged into
plone.app.toolbar. IMO, toolbar is the next step after solving the obvious
issues we have right now and I think toolbar can carry on while we fix our
current state of things.

Regarding bootstrap: yes, I think we should definitely explore using it.
I'm prefer plone to end up looking just like another bootstrap site. People
are going to start getting really annoyed with the bootstrap styled sites
and we don't need all plone sites looking like them. So, if we do it, we
need it to be bootstrap, but customized a bit to not completely be
bootstrap.

Also, I think we're pretty invested in bootstrap already since we're using
it for toolbar. I really don't want to exercise the thought of using
bootstrap for toolbar and then some other css framework for the rest of the
UI.

Another interesting way to do it is namespacing the bootstrap css rules. I
do that in wildcard.foldercontents and the latest
plone.app.workflowmanager. Allows you to easily bootstrap only certain
elements, not all of the UI.

I've added a ticket so I can wrap all the idea up:
https://dev.plone.org/ticket/13140

Once I start create mockups, I'll create new tickets and we can start
dolling out the work.



On Wed, Aug 29, 2012 at 9:20 AM, Elizabeth Leddy
<elizabeth.leddy@...:

>
>
> On Aug 29, 2012, at 6:57 AM, Wichert Akkerman wrote:
>
> > On 2012-8-29 11:53, Martin Aspeli wrote:
> >> I think there is merit in trying to use a more fully-featured CSS
> >> framework, mainly because none of us are good enough with CSS to do as
> >> good a job. :) Having well-structured, reusable elements in our CSS is
> >> (and has been) key to making sure add-ons look and work consistently
> >> with the rest of Plone.
> >
> > To put this in a bit of perspective: Plone used to have well-structured
> > reusable elements in its HTML & CSS. What killed it though was the
> > complete lack of documentation which led to people not using those
> > elements or using them incorrectly. And that is where twitter bootstrap
> > shines: it is not really that much better than other CSS frameworks, but
> > it is very well documented. There is a lesson to be learned here.
>
> I remember those days, and I remember having to use !important after every
> new rule I ever tried to add. That being said, I am jumping out of my seat
> with the idea of a non-plone community managed style framework and I don't
> see bootstrap going anywhere in the medium term.
>
> However, to really jump into bootstrap I *think* we should go all or
> nothing in committing to the change. Piece-mealing isn't going to be worth
> it and it will be an upgrade disaster. Additionally, we can't expect people
> to know what is bootstrap and what is plone and what is just random shit
> floating around.
>
> That being said, I would be willing to commit a significant effort to this
> implementation wise - I have lots of experience with bootstrap and have
> been plone cssing since day 1. Has anything been started on this already?
>
> Thanks nathan for getting this started! Sign me up on the list of people
> to help with implementation. I spend a good chunk of time rewriting
> interfaces on every new project so for me (and future clients!) this is a
> big win.
>
> Liz
>
> >
> > Wichert.
> >
> > --
> > Wichert Akkerman <wichert@...>   It is simple to make things.
> > http://www.wiggy.net/                  It is hard to make things simple.
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Plone-developers mailing list
> > Plone-developers@...
> > https://lists.sourceforge.net/lists/listinfo/plone-developers
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>

On 2012-08-29 10:24, Jean-Michel FRANCOIS wrote:
> I have done some UI experiment to remove search server side for users
> using datatables in many screens on a customer project:
>
> * sharing
> * users controlpanel for all tabs
>
> The results is a blazing fast user search UI. We have done this on an
> intranet with 10K users.
>
> I'm ready to propose a plip to move that code into Plone.  For sure with
> 100k users We should have a better server side search engine (zcatalog ?)
>
> Regards / Cordialement,
> JeanMichel FRANCOIS

+` for jquery.datatables withs its json api to fetch the data for most 
of table-data, i.e. folder_contents.

Jens
-- 
Klein & Partner KG, member of BlueDynamics Alliance

Hi,

On 29 August 2012 16:27, Nathan Van Gheem <vangheem@...> wrote:

> Thank you everyone for the input. I'll provide some responses.
>
>
>> Dylan:
>
> I'd like to add guidelines for where to put add in functionality from
>> plugins. For example, if I write a plugin, there seems to be somewhat
>> random places functionality turns up. In eea.facetednavigation you enable
>> it via a folders action menu which is weird, and then you get a extra
>> document tab to edit the settings. Lineage you use the the sub-type menu to
>> enable lineage. I think perhaps there needs to some thought into the kinds
>> of ways 3rd party plugins seem to want to integrate into plone and plone
>> could be changed to make those appear in an obvious way. I'm hoping that
>> plone.app.toolbar and deco will solve some of these issues.
>
> Agreed
>
>
>
>> To tackle this, we'll focus on these things:
>>> 1) Provide obvious fixes and improvements to plone's existing UI failures
>>> 2) Provide guidelines to developers in user testing new UI. The work
>>> that martin and the developers at UCLA did is valuable in this respect.
>>> 3) Make decisions and implement new widgets, js libraries and
>>> testing infrastructure.
>>>  One thing I'm not going to currently address is future deco related UI
>>> concerns.
>>> What about the plone.app.cmsui effort? I felt that actually made some
>>> important strides, not the least of which is making Diazo theming a lot
>>> easier (and breaking the editing UI a lot harder). Personally, I feel
>>> that's an effort worth pushing through even if the overlays are virtually
>>> identical to the respective bits of UI today initially. It's also separate
>>> from Deco.
>>>
>> Martin, as far as I understand, cmsui is going to be merged into
> plone.app.toolbar. IMO, toolbar is the next step after solving the obvious
> issues we have right now and I think toolbar can carry on while we fix our
> current state of things.
>

+1


> Regarding bootstrap: yes, I think we should definitely explore using it.
> I'm prefer plone to end up looking just like another bootstrap site. People
> are going to start getting really annoyed with the bootstrap styled sites
> and we don't need all plone sites looking like them. So, if we do it, we
> need it to be bootstrap, but customized a bit to not completely be
> bootstrap.
>

+1 - it's fairly well structured, and making visual changes whilst
retaining the structural benefits shouldn't be that hard. There are even
free/commercial "themes" for Bootstrap out there that does this.


> Also, I think we're pretty invested in bootstrap already since we're using
> it for toolbar. I really don't want to exercise the thought of using
> bootstrap for toolbar and then some other css framework for the rest of the
> UI.
>

Agreed.


> Another interesting way to do it is namespacing the bootstrap css rules. I
> do that in wildcard.foldercontents and the latest
> plone.app.workflowmanager. Allows you to easily bootstrap only certain
> elements, not all of the UI.
>
> I've added a ticket so I can wrap all the idea up:
> https://dev.plone.org/ticket/13140
>
> Once I start create mockups, I'll create new tickets and we can start
> dolling out the work.
>

Cool!

Martin

It would be interesting to also have new Javascript in Plone written in
"html5 data attributes" style like twitter bootstrap javascript components
do[0] (and also projects like Patterns[1]). This brings opportunity to
configure Javascript plugins with html tag attributes and nothing more
(basically inverted logic of KSS) :)

[0] http://twitter.github.com/bootstrap/javascript.html#overview
[1] https://github.com/cornae/Patterns/blob/master/demo/collapsible.html

On Wed, Aug 29, 2012 at 5:50 PM, Martin Aspeli <optilude+lists@...:

> Hi,
>
> On 29 August 2012 16:27, Nathan Van Gheem <vangheem@...> wrote:
>
>> Thank you everyone for the input. I'll provide some responses.
>>
>>
>>> Dylan:
>>
>> I'd like to add guidelines for where to put add in functionality from
>>> plugins. For example, if I write a plugin, there seems to be somewhat
>>> random places functionality turns up. In eea.facetednavigation you enable
>>> it via a folders action menu which is weird, and then you get a extra
>>> document tab to edit the settings. Lineage you use the the sub-type menu to
>>> enable lineage. I think perhaps there needs to some thought into the kinds
>>> of ways 3rd party plugins seem to want to integrate into plone and plone
>>> could be changed to make those appear in an obvious way. I'm hoping that
>>> plone.app.toolbar and deco will solve some of these issues.
>>
>> Agreed
>>
>>
>>
>>> To tackle this, we'll focus on these things:
>>>> 1) Provide obvious fixes and improvements to plone's existing UI
>>>> failures
>>>> 2) Provide guidelines to developers in user testing new UI. The work
>>>> that martin and the developers at UCLA did is valuable in this respect.
>>>> 3) Make decisions and implement new widgets, js libraries and
>>>> testing infrastructure.
>>>>  One thing I'm not going to currently address is future deco related UI
>>>> concerns.
>>>> What about the plone.app.cmsui effort? I felt that actually made some
>>>> important strides, not the least of which is making Diazo theming a lot
>>>> easier (and breaking the editing UI a lot harder). Personally, I feel
>>>> that's an effort worth pushing through even if the overlays are virtually
>>>> identical to the respective bits of UI today initially. It's also separate
>>>> from Deco.
>>>>
>>> Martin, as far as I understand, cmsui is going to be merged into
>> plone.app.toolbar. IMO, toolbar is the next step after solving the obvious
>> issues we have right now and I think toolbar can carry on while we fix our
>> current state of things.
>>
>
> +1
>
>
>> Regarding bootstrap: yes, I think we should definitely explore using it.
>> I'm prefer plone to end up looking just like another bootstrap site. People
>> are going to start getting really annoyed with the bootstrap styled sites
>> and we don't need all plone sites looking like them. So, if we do it, we
>> need it to be bootstrap, but customized a bit to not completely be
>> bootstrap.
>>
>
> +1 - it's fairly well structured, and making visual changes whilst
> retaining the structural benefits shouldn't be that hard. There are even
> free/commercial "themes" for Bootstrap out there that does this.
>
>
>> Also, I think we're pretty invested in bootstrap already since we're
>> using it for toolbar. I really don't want to exercise the thought of using
>> bootstrap for toolbar and then some other css framework for the rest of the
>> UI.
>>
>
> Agreed.
>
>
>> Another interesting way to do it is namespacing the bootstrap css rules.
>> I do that in wildcard.foldercontents and the latest
>> plone.app.workflowmanager. Allows you to easily bootstrap only certain
>> elements, not all of the UI.
>>
>> I've added a ticket so I can wrap all the idea up:
>> https://dev.plone.org/ticket/13140
>>
>> Once I start create mockups, I'll create new tickets and we can start
>> dolling out the work.
>>
>
> Cool!
>
> Martin
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>
>

On 30/08/2012, at 1:27 AM, Nathan Van Gheem wrote:

> Thank you everyone for the input. I'll provide some responses.
>>
>>> To tackle this, we'll focus on these things:
>>> 1) Provide obvious fixes and improvements to plone's existing UI  
>>> failures
>>> 2) Provide guidelines to developers in user testing new UI. The  
>>> work that martin and the developers at UCLA did is valuable in  
>>> this respect.
>>> 3) Make decisions and implement new widgets, js libraries and  
>>> testing infrastructure.
>>> One thing I'm not going to currently address is future deco  
>>> related UI concerns.
>>>
>> What about the plone.app.cmsui effort? I felt that actually made  
>> some important strides, not the least of which is making Diazo  
>> theming a lot easier (and breaking the editing UI a lot harder).  
>> Personally, I feel that's an effort worth pushing through even if  
>> the overlays are virtually identical to the respective bits of UI  
>> today initially. It's also separate from Deco.
> Martin, as far as I understand, cmsui is going to be merged into  
> plone.app.toolbar. IMO, toolbar is the next step after solving the  
> obvious issues we have right now and I think toolbar can carry on  
> while we fix our current state of things.

 From talking to Rok my understanding was that plone.app.toolbar has  
been brought up to a level where it's functions are exactly like the  
green bar. It has been made "extendable" such that other efforts such  
as deco, cmsui or other new UI ideas can add things into it easily. No  
one is currently merging the new UI concepts from CMSUI into  
plone.app.toolbar that I know of. I may be out of date on this however.
Given that any new UI enhancements would have to be back ported into  
plone.app.toolbar wouldn't it make sense to build on top of  
plone.app.toolbar?

The reason I'm pushing this is that p.a.toolbar is important. I'm not  
sure if everyone in this thread is using diazo on a regular basis so  
in case they aren't I want to spell out how important it is. When you  
theme a site using diazo you have two choices. You either
a) theme the public site only and give the users two urls, and admin  
interface unthemed (say using sunburst).
b) integrate parts of the plone css and add rules into diazo such that  
the Plone UI still works in your theme.

Choice B adds 1-2 days to your theming time (more or less doubling the  
time to theme) and a lot more experience is needed as there are lots  
of gotchas. B also doesn't work well with the new theming editor as it  
assumes your css is independent of portal_css in it's preview mode.

Choice A means you lose out on one the nicest aspects of Plone's UI,  
in-context editing. Suddenly you have two UI's in two different  
browser tabs.

Plone.app.toolbar combines the best of both worlds, in-context editing  
and theming in under a day with less skill required. It has no  
dependency on deco or CMSUI. I very much agree with Martin it's worth  
pushing though. Is the reluctance to use it based on it's perceived  
link to CMSUI or deco or is there something else I'm missing?

There's actually a third way

c) theme the public site and give the users two urls, inserting a
preview iframe into the admin interface using a diazo rule

At the moment this is a low cost half way house:  You don't have to
spend money implementing Plone's UI in your theme but your editors
still get to see what pages look like

It is probably the best approach for the design of our site ,
http://www.our-africa.org/ which has quite an unusual navigation.  The
iframe approach is not suitable for community driven websites but
might be optimal for sites with lots of visitors and a handful of
dedicated editors.  I can't help think that if people who's full time
job is to edit content you want the most usable editing experience and
that will most easily come from Plone's default UI

Anthony

On 30 August 2012 01:18, Dylan Jay <djay@...> wrote:
> On 30/08/2012, at 1:27 AM, Nathan Van Gheem wrote:
>
>> Thank you everyone for the input. I'll provide some responses.
>>>
>>>> To tackle this, we'll focus on these things:
>>>> 1) Provide obvious fixes and improvements to plone's existing UI
>>>> failures
>>>> 2) Provide guidelines to developers in user testing new UI. The
>>>> work that martin and the developers at UCLA did is valuable in
>>>> this respect.
>>>> 3) Make decisions and implement new widgets, js libraries and
>>>> testing infrastructure.
>>>> One thing I'm not going to currently address is future deco
>>>> related UI concerns.
>>>>
>>> What about the plone.app.cmsui effort? I felt that actually made
>>> some important strides, not the least of which is making Diazo
>>> theming a lot easier (and breaking the editing UI a lot harder).
>>> Personally, I feel that's an effort worth pushing through even if
>>> the overlays are virtually identical to the respective bits of UI
>>> today initially. It's also separate from Deco.
>> Martin, as far as I understand, cmsui is going to be merged into
>> plone.app.toolbar. IMO, toolbar is the next step after solving the
>> obvious issues we have right now and I think toolbar can carry on
>> while we fix our current state of things.
>
>  From talking to Rok my understanding was that plone.app.toolbar has
> been brought up to a level where it's functions are exactly like the
> green bar. It has been made "extendable" such that other efforts such
> as deco, cmsui or other new UI ideas can add things into it easily. No
> one is currently merging the new UI concepts from CMSUI into
> plone.app.toolbar that I know of. I may be out of date on this however.
> Given that any new UI enhancements would have to be back ported into
> plone.app.toolbar wouldn't it make sense to build on top of
> plone.app.toolbar?
>
> The reason I'm pushing this is that p.a.toolbar is important. I'm not
> sure if everyone in this thread is using diazo on a regular basis so
> in case they aren't I want to spell out how important it is. When you
> theme a site using diazo you have two choices. You either
> a) theme the public site only and give the users two urls, and admin
> interface unthemed (say using sunburst).
> b) integrate parts of the plone css and add rules into diazo such that
> the Plone UI still works in your theme.
>
> Choice B adds 1-2 days to your theming time (more or less doubling the
> time to theme) and a lot more experience is needed as there are lots
> of gotchas. B also doesn't work well with the new theming editor as it
> assumes your css is independent of portal_css in it's preview mode.
>
> Choice A means you lose out on one the nicest aspects of Plone's UI,
> in-context editing. Suddenly you have two UI's in two different
> browser tabs.
>
> Plone.app.toolbar combines the best of both worlds, in-context editing
> and theming in under a day with less skill required. It has no
> dependency on deco or CMSUI. I very much agree with Martin it's worth
> pushing though. Is the reluctance to use it based on it's perceived
> link to CMSUI or deco or is there something else I'm missing?
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers

On 30/08/2012, at 5:53 PM, Anthony Gerrard wrote:

> There's actually a third way
>
> c) theme the public site and give the users two urls, inserting a
> preview iframe into the admin interface using a diazo rule
>
> At the moment this is a low cost half way house:  You don't have to
> spend money implementing Plone's UI in your theme but your editors
> still get to see what pages look like
>
> It is probably the best approach for the design of our site ,
> http://www.our-africa.org/ which has quite an unusual navigation.  The
> iframe approach is not suitable for community driven websites but
> might be optimal for sites with lots of visitors and a handful of
> dedicated editors.  I can't help think that if people who's full time
> job is to edit content you want the most usable editing experience and
> that will most easily come from Plone's default UI

That's a really neat solution. And not that different from what  
plone.app.toolbar does.
Just to prove that it does work and doesn't do anything different  
functionality-wise from normal plone, here is what it looks like.

On 30 August 2012 09:36, Dylan Jay <djay@...> wrote:
> I guess for your site adding in a file browser and breadcrumbs into the
> toolbar (as was in CMSUI) might also be handy since your site is missing
> some navigation features.

Yes, if a navigation was added to the toolbar then it would be like
our current solution only better

Can everyone please keep me out of the cc? I read plone-developers 
directly, so there is no need to cc me.


On 08/30/2012 10:36 AM, Dylan Jay wrote:
>
> On 30/08/2012, at 5:53 PM, Anthony Gerrard wrote:
>
>> There's actually a third way
>>
>> c) theme the public site and give the users two urls, inserting a
>> preview iframe into the admin interface using a diazo rule
>>
>> At the moment this is a low cost half way house:  You don't have to
>> spend money implementing Plone's UI in your theme but your editors
>> still get to see what pages look like
>>
>> It is probably the best approach for the design of our site ,
>> http://www.our-africa.org/ which has quite an unusual navigation.  The
>> iframe approach is not suitable for community driven websites but
>> might be optimal for sites with lots of visitors and a handful of
>> dedicated editors.  I can't help think that if people who's full time
>> job is to edit content you want the most usable editing experience and
>> that will most easily come from Plone's default UI
>
> That's a really neat solution. And not that different from what 
> plone.app.toolbar does.
> Just to prove that it does work and doesn't do anything different 
> functionality-wise from normal plone, here is what it looks like.
>
>
>
>
> I guess for your site adding in a file browser and breadcrumbs into 
> the toolbar (as was in CMSUI) might also be handy since your site is 
> missing some navigation features.
>
> One thing I was thinking about was improving the dashboard by making 
> it into an additional toolbar. The dashboard could be made into 
> vertical toolbar on the left of the page which could be optionally 
> kept open or closed. The user could then add productivity portlets to 
> help them in their day to day activities without having to switch 
> page. For example, favourites, recently visited, actions portlet. The 
> portlets could use a dynamic accordion to save space. Since the 
> dashboard has 4 columns you could pull it out left to right, one 
> column at a time. More frequently useful portlets on the left and less 
> on the right.
>
>
>
>>
>> Anthony
>>
>> On 30 August 2012 01:18, Dylan Jay <djay@...> wrote:
>>> On 30/08/2012, at 1:27 AM, Nathan Van Gheem wrote:
>>>
>>>> Thank you everyone for the input. I'll provide some responses.
>>>>>
>>>>>> To tackle this, we'll focus on these things:
>>>>>> 1) Provide obvious fixes and improvements to plone's existing UI
>>>>>> failures
>>>>>> 2) Provide guidelines to developers in user testing new UI. The
>>>>>> work that martin and the developers at UCLA did is valuable in
>>>>>> this respect.
>>>>>> 3) Make decisions and implement new widgets, js libraries and
>>>>>> testing infrastructure.
>>>>>> One thing I'm not going to currently address is future deco
>>>>>> related UI concerns.
>>>>>>
>>>>> What about the plone.app.cmsui effort? I felt that actually made
>>>>> some important strides, not the least of which is making Diazo
>>>>> theming a lot easier (and breaking the editing UI a lot harder).
>>>>> Personally, I feel that's an effort worth pushing through even if
>>>>> the overlays are virtually identical to the respective bits of UI
>>>>> today initially. It's also separate from Deco.
>>>> Martin, as far as I understand, cmsui is going to be merged into
>>>> plone.app.toolbar. IMO, toolbar is the next step after solving the
>>>> obvious issues we have right now and I think toolbar can carry on
>>>> while we fix our current state of things.
>>>
>>> From talking to Rok my understanding was that plone.app.toolbar has
>>> been brought up to a level where it's functions are exactly like the
>>> green bar. It has been made "extendable" such that other efforts such
>>> as deco, cmsui or other new UI ideas can add things into it easily. No
>>> one is currently merging the new UI concepts from CMSUI into
>>> plone.app.toolbar that I know of. I may be out of date on this however.
>>> Given that any new UI enhancements would have to be back ported into
>>> plone.app.toolbar wouldn't it make sense to build on top of
>>> plone.app.toolbar?
>>>
>>> The reason I'm pushing this is that p.a.toolbar is important. I'm not
>>> sure if everyone in this thread is using diazo on a regular basis so
>>> in case they aren't I want to spell out how important it is. When you
>>> theme a site using diazo you have two choices. You either
>>> a) theme the public site only and give the users two urls, and admin
>>> interface unthemed (say using sunburst).
>>> b) integrate parts of the plone css and add rules into diazo such that
>>> the Plone UI still works in your theme.
>>>
>>> Choice B adds 1-2 days to your theming time (more or less doubling the
>>> time to theme) and a lot more experience is needed as there are lots
>>> of gotchas. B also doesn't work well with the new theming editor as it
>>> assumes your css is independent of portal_css in it's preview mode.
>>>
>>> Choice A means you lose out on one the nicest aspects of Plone's UI,
>>> in-context editing. Suddenly you have two UI's in two different
>>> browser tabs.
>>>
>>> Plone.app.toolbar combines the best of both worlds, in-context editing
>>> and theming in under a day with less skill required. It has no
>>> dependency on deco or CMSUI. I very much agree with Martin it's worth
>>> pushing though. Is the reluctance to use it based on it's perceived
>>> link to CMSUI or deco or is there something else I'm missing?
>>>
>>> ------------------------------------------------------------------------------ 
>>>
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. 
>>> Discussions
>>> will include endpoint security, mobile security and the latest in 
>>> malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Plone-developers mailing list
>>> Plone-developers@...
>>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers

>
> One thing I was thinking about was improving the dashboard by making it
> into an additional toolbar. The dashboard could be made into vertical
> toolbar on the left of the page which could be optionally kept open or
> closed. The user could then add productivity portlets to help them in their
> day to day activities without having to switch page. For example,
> favourites, recently visited, actions portlet. The portlets could use a
> dynamic accordion to save space. Since the dashboard has 4 columns you
> could pull it out left to right, one column at a time. More frequently
> useful portlets on the left and less on the right.

I like this idea. Bringing it one step further, you could also have it
handle communication and notifications. Sort of like mountain lion's
notification center that can be hidden and expanded.

On Thu, Aug 30, 2012 at 3:36 AM, Dylan Jay <djay@...> wrote:

>
> On 30/08/2012, at 5:53 PM, Anthony Gerrard wrote:
>
>  There's actually a third way
>>
>> c) theme the public site and give the users two urls, inserting a
>> preview iframe into the admin interface using a diazo rule
>>
>> At the moment this is a low cost half way house:  You don't have to
>> spend money implementing Plone's UI in your theme but your editors
>> still get to see what pages look like
>>
>> It is probably the best approach for the design of our site ,
>> http://www.our-africa.org/ which has quite an unusual navigation.  The
>> iframe approach is not suitable for community driven websites but
>> might be optimal for sites with lots of visitors and a handful of
>> dedicated editors.  I can't help think that if people who's full time
>> job is to edit content you want the most usable editing experience and
>> that will most easily come from Plone's default UI
>>
>
> That's a really neat solution. And not that different from what
> plone.app.toolbar does.
> Just to prove that it does work and doesn't do anything different
> functionality-wise from normal plone, here is what it looks like.
>
>
>
>
>
> I guess for your site adding in a file browser and breadcrumbs into the
> toolbar (as was in CMSUI) might also be handy since your site is missing
> some navigation features.
>
> One thing I was thinking about was improving the dashboard by making it
> into an additional toolbar. The dashboard could be made into vertical
> toolbar on the left of the page which could be optionally kept open or
> closed. The user could then add productivity portlets to help them in their
> day to day activities without having to switch page. For example,
> favourites, recently visited, actions portlet. The portlets could use a
> dynamic accordion to save space. Since the dashboard has 4 columns you
> could pull it out left to right, one column at a time. More frequently
> useful portlets on the left and less on the right.
>
>
>
>
>> Anthony
>>
>> On 30 August 2012 01:18, Dylan Jay <djay@...> wrote:
>>
>>> On 30/08/2012, at 1:27 AM, Nathan Van Gheem wrote:
>>>
>>>  Thank you everyone for the input. I'll provide some responses.
>>>>
>>>>>
>>>>>  To tackle this, we'll focus on these things:
>>>>>> 1) Provide obvious fixes and improvements to plone's existing UI
>>>>>> failures
>>>>>> 2) Provide guidelines to developers in user testing new UI. The
>>>>>> work that martin and the developers at UCLA did is valuable in
>>>>>> this respect.
>>>>>> 3) Make decisions and implement new widgets, js libraries and
>>>>>> testing infrastructure.
>>>>>> One thing I'm not going to currently address is future deco
>>>>>> related UI concerns.
>>>>>>
>>>>>>  What about the plone.app.cmsui effort? I felt that actually made
>>>>> some important strides, not the least of which is making Diazo
>>>>> theming a lot easier (and breaking the editing UI a lot harder).
>>>>> Personally, I feel that's an effort worth pushing through even if
>>>>> the overlays are virtually identical to the respective bits of UI
>>>>> today initially. It's also separate from Deco.
>>>>>
>>>> Martin, as far as I understand, cmsui is going to be merged into
>>>> plone.app.toolbar. IMO, toolbar is the next step after solving the
>>>> obvious issues we have right now and I think toolbar can carry on
>>>> while we fix our current state of things.
>>>>
>>>
>>> From talking to Rok my understanding was that plone.app.toolbar has
>>> been brought up to a level where it's functions are exactly like the
>>> green bar. It has been made "extendable" such that other efforts such
>>> as deco, cmsui or other new UI ideas can add things into it easily. No
>>> one is currently merging the new UI concepts from CMSUI into
>>> plone.app.toolbar that I know of. I may be out of date on this however.
>>> Given that any new UI enhancements would have to be back ported into
>>> plone.app.toolbar wouldn't it make sense to build on top of
>>> plone.app.toolbar?
>>>
>>> The reason I'm pushing this is that p.a.toolbar is important. I'm not
>>> sure if everyone in this thread is using diazo on a regular basis so
>>> in case they aren't I want to spell out how important it is. When you
>>> theme a site using diazo you have two choices. You either
>>> a) theme the public site only and give the users two urls, and admin
>>> interface unthemed (say using sunburst).
>>> b) integrate parts of the plone css and add rules into diazo such that
>>> the Plone UI still works in your theme.
>>>
>>> Choice B adds 1-2 days to your theming time (more or less doubling the
>>> time to theme) and a lot more experience is needed as there are lots
>>> of gotchas. B also doesn't work well with the new theming editor as it
>>> assumes your css is independent of portal_css in it's preview mode.
>>>
>>> Choice A means you lose out on one the nicest aspects of Plone's UI,
>>> in-context editing. Suddenly you have two UI's in two different
>>> browser tabs.
>>>
>>> Plone.app.toolbar combines the best of both worlds, in-context editing
>>> and theming in under a day with less skill required. It has no
>>> dependency on deco or CMSUI. I very much agree with Martin it's worth
>>> pushing though. Is the reluctance to use it based on it's perceived
>>> link to CMSUI or deco or is there something else I'm missing?
>>>
>>> ------------------------------**------------------------------**
>>> ------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/**sfrnl04242012/114/50122263/<http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/>
>>> ______________________________**_________________
>>> Plone-developers mailing list
>>> Plone-developers@...>
>>> https://lists.sourceforge.net/**lists/listinfo/plone-**developers<https://lists.sourceforge.net/lists/listinfo/plone-developers>
>>>
>>
>
>

On 30 August 2012 14:07, Nathan Van Gheem <vangheem@...> wrote:

> One thing I was thinking about was improving the dashboard by making it
>> into an additional toolbar. The dashboard could be made into vertical
>> toolbar on the left of the page which could be optionally kept open or
>> closed. The user could then add productivity portlets to help them in their
>> day to day activities without having to switch page. For example,
>> favourites, recently visited, actions portlet. The portlets could use a
>> dynamic accordion to save space. Since the dashboard has 4 columns you
>> could pull it out left to right, one column at a time. More frequently
>> useful portlets on the left and less on the right.
>
> I like this idea. Bringing it one step further, you could also have it
> handle communication and notifications. Sort of like mountain lion's
> notification center that can be hidden and expanded
>

I wonder whether,  as we try to shift the focus and, to an extent, purpose
of the dashboard, we should try to make it use tiles rather than portlets.
And maybe the same for the left/right columns as well. The main benefit
would be integrator friendliness. The main downside would be migration and
documentation.

More broadly, I think we should try to take a position on whether
p.a.toolbar is a strong near-term goal for Plone's UI. (IMHO it should be
and we should push to make it happen).

Martin

On Thursday, August 30, 2012 at 9:34 AM, Martin Aspeli wrote:
> On 30 August 2012 14:07, Nathan Van Gheem <vangheem@... (mailto:vangheem@...)> wrote:
> > > One thing I was thinking about was improving the dashboard by making it into an additional toolbar. The dashboard could be made into vertical toolbar on the left of the page which could be optionally kept open or closed. The user could then add productivity portlets to help them in their day to day activities without having to switch page. For example, favourites, recently visited, actions portlet. The portlets could use a dynamic accordion to save space. Since the dashboard has 4 columns you could pull it out left to right, one column at a time. More frequently useful portlets on the left and less on the right.
> > I like this idea. Bringing it one step further, you could also have it handle communication and notifications. Sort of like mountain lion's notification center that can be hidden and expanded
> > 
> 
> 
> I wonder whether,  as we try to shift the focus and, to an extent, purpose of the dashboard, we should try to make it use tiles rather than portlets. And maybe the same for the left/right columns as well. The main benefit would be integrator friendliness. The main downside would be migration and documentation. 
> 
> More broadly, I think we should try to take a position on whether p.a.toolbar is a strong near-term goal for Plone's UI. (IMHO it should be and we should push to make it happen).
> 
> Martin

On plone.app.toolbar: I think it absolutely is. Diazo is only 80% of a solution until we've got the editing/management interface working with it. I think I did a poor job of explaining my position, but the main reason I was stumping to push Deco Lite to the background (near-term) was so that we could get the toolbar finished and in core as soon as possible.

Eric

On 30/08/2012, at 11:34 PM, Martin Aspeli wrote:

>
>
> On 30 August 2012 14:07, Nathan Van Gheem <vangheem@...> wrote:
> One thing I was thinking about was improving the dashboard by making  
> it into an additional toolbar. The dashboard could be made into  
> vertical toolbar on the left of the page which could be optionally  
> kept open or closed. The user could then add productivity portlets  
> to help them in their day to day activities without having to switch  
> page. For example, favourites, recently visited, actions portlet.  
> The portlets could use a dynamic accordion to save space. Since the  
> dashboard has 4 columns you could pull it out left to right, one  
> column at a time. More frequently useful portlets on the left and  
> less on the right.
> I like this idea. Bringing it one step further, you could also have  
> it handle communication and notifications. Sort of like mountain  
> lion's notification center that can be hidden and expanded
>
> I wonder whether,  as we try to shift the focus and, to an extent,  
> purpose of the dashboard, we should try to make it use tiles rather  
> than portlets. And maybe the same for the left/right columns as  
> well. The main benefit would be integrator friendliness. The main  
> downside would be migration and documentation.

I was thinking start with portlets first so anyone using dashboards  
now could take advantage of it. Then when deco gets popular we can  
think about how to replace the dashboard portlets with tiles.

but you make a good point. The dashboard doesn't seem to be widely  
used at the moment from my experience so maybe its another way of  
getting tiles into the Plone UI earlier? Many of the portlets I  
mention above don't exist yet (e.g. recently visited) so making them  
as tiles would be much easier and future proof than doing them as  
portlets.


>
> More broadly, I think we should try to take a position on whether  
> p.a.toolbar is a strong near-term goal for Plone's UI. (IMHO it  
> should be and we should push to make it happen).

+1

>
> Martin

I was in the rather unique position to closely observe a large group of
people completely new to Plone working with it. In case, 50+ women from
all over Asia, working with our intranet. Far from being computer
experts, they are garment workers and union activists.

Overall, a rather pleasing experience. Kudos to Plone, they all more or
less managed within a few hours. Which is pretty amazing, once you think
about it properly.

There's just a few items that annoyed and confused them, and I can only
concur. Plus, I think they should be fixable. This would immensely
improve user experience.

So, my question to you is, should any of this be PLIP'd?

- TinyMCE's 'paste from Word' button. It does a commendable job of
filtering out Word/OpenOffice crap. The problem is, it's hard for
editors to decide when to use this, and when to just hit Ctrl-V to paste.
To me, this sounds like a decision editors shouldn't have to make. What
would be the downside of just always filtering out crap? Performance?
Inability to paste code? Can't we make TinyMCE recognize obvious Word
crap, and then just automagically do the right thing?

- the Tags/Keywords widget is still not very useable in 4.2, even though
it has improved. But for a non-trivial site, it still sucks when a few
hundred keywords are present. eea.tags solves this with an interface
that "just works" for anybody who has ever used Facebook/twitter/Weibo.
Combined, that's about 1.5 billion people. Go with the flow.

- despite my trying, there is no way I can explain logically why
NewsItems can have an image associated, and Pages dont. I routinely
install ContentLeadImage in every site, but this seems backwards, and
leads to user interface inconsistency. Shouldn't this be some kind of
standard, in the future a dexterity behaviour, that integrators can
switch on and off per contenttype?

Paul Roeland

On 9/7/12 2:23 PM, polyester wrote:
> I was in the rather unique position to closely observe a large group of
> people completely new to Plone working with it. In case, 50+ women from
> all over Asia, working with our intranet. Far from being computer
> experts, they are garment workers and union activists.
>
> Overall, a rather pleasing experience. Kudos to Plone, they all more or
> less managed within a few hours. Which is pretty amazing, once you think
> about it properly.

Cool!

>
> There's just a few items that annoyed and confused them, and I can only
> concur. Plus, I think they should be fixable. This would immensely
> improve user experience.
>
> So, my question to you is, should any of this be PLIP'd?
>
> - TinyMCE's 'paste from Word' button. It does a commendable job of
> filtering out Word/OpenOffice crap. The problem is, it's hard for
> editors to decide when to use this, and when to just hit Ctrl-V to paste.
> To me, this sounds like a decision editors shouldn't have to make. What
> would be the downside of just always filtering out crap? Performance?
> Inability to paste code? Can't we make TinyMCE recognize obvious Word
> crap, and then just automagically do the right thing?

According to http://www.tinymce.com/wiki.php/Plugin:paste, TinyMCE now 
has support for this. Maybe we just need to turn it on?

> - the Tags/Keywords widget is still not very useable in 4.2, even though
> it has improved. But for a non-trivial site, it still sucks when a few
> hundred keywords are present. eea.tags solves this with an interface
> that "just works" for anybody who has ever used Facebook/twitter/Weibo.
> Combined, that's about 1.5 billion people. Go with the flow.

+1 for a better widget, as long as it remains accessible, which was a 
key goal of the current widget.

> - despite my trying, there is no way I can explain logically why
> NewsItems can have an image associated, and Pages dont. I routinely
> install ContentLeadImage in every site, but this seems backwards, and
> leads to user interface inconsistency. Shouldn't this be some kind of
> standard, in the future a dexterity behaviour, that integrators can
> switch on and off per contenttype?
>

+1; this has been a common request from Groundwire clients.

On Sep 7, 2012, at 2:31 PM, David Glick (Plone) wrote:

> On 9/7/12 2:23 PM, polyester wrote:
>> I was in the rather unique position to closely observe a large group of
>> people completely new to Plone working with it. In case, 50+ women from
>> all over Asia, working with our intranet. Far from being computer
>> experts, they are garment workers and union activists.
>> 
>> Overall, a rather pleasing experience. Kudos to Plone, they all more or
>> less managed within a few hours. Which is pretty amazing, once you think
>> about it properly.
> 
> Cool!
> 
>> 
>> There's just a few items that annoyed and confused them, and I can only
>> concur. Plus, I think they should be fixable. This would immensely
>> improve user experience.
>> 
>> So, my question to you is, should any of this be PLIP'd?
>> 
>> - TinyMCE's 'paste from Word' button. It does a commendable job of
>> filtering out Word/OpenOffice crap. The problem is, it's hard for
>> editors to decide when to use this, and when to just hit Ctrl-V to paste.
>> To me, this sounds like a decision editors shouldn't have to make. What
>> would be the downside of just always filtering out crap? Performance?
>> Inability to paste code? Can't we make TinyMCE recognize obvious Word
>> crap, and then just automagically do the right thing?
> 
> According to http://www.tinymce.com/wiki.php/Plugin:paste, TinyMCE now 
> has support for this. Maybe we just need to turn it on?
> 
>> - the Tags/Keywords widget is still not very useable in 4.2, even though
>> it has improved. But for a non-trivial site, it still sucks when a few
>> hundred keywords are present. eea.tags solves this with an interface
>> that "just works" for anybody who has ever used Facebook/twitter/Weibo.
>> Combined, that's about 1.5 billion people. Go with the flow.
> 
> +1 for a better widget, as long as it remains accessible, which was a 
> key goal of the current widget.

Please, please someone plip this....

Liz

> 
>> - despite my trying, there is no way I can explain logically why
>> NewsItems can have an image associated, and Pages dont. I routinely
>> install ContentLeadImage in every site, but this seems backwards, and
>> leads to user interface inconsistency. Shouldn't this be some kind of
>> standard, in the future a dexterity behaviour, that integrators can
>> switch on and off per contenttype?
>> 
> 
> +1; this has been a common request from Groundwire clients.
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers

This is awesome, sensible feedback.  Thanks for taking the time to
write it up and share!

:jon


On Fri, Sep 7, 2012 at 2:23 PM, polyester <paula@...> wrote:
> I was in the rather unique position to closely observe a large group of
> people completely new to Plone working with it. In case, 50+ women from
> all over Asia, working with our intranet. Far from being computer
> experts, they are garment workers and union activists.
>
> Overall, a rather pleasing experience. Kudos to Plone, they all more or
> less managed within a few hours. Which is pretty amazing, once you think
> about it properly.
>
> There's just a few items that annoyed and confused them, and I can only
> concur. Plus, I think they should be fixable. This would immensely
> improve user experience.
>
> So, my question to you is, should any of this be PLIP'd?
>
> - TinyMCE's 'paste from Word' button. It does a commendable job of
> filtering out Word/OpenOffice crap. The problem is, it's hard for
> editors to decide when to use this, and when to just hit Ctrl-V to paste.
> To me, this sounds like a decision editors shouldn't have to make. What
> would be the downside of just always filtering out crap? Performance?
> Inability to paste code? Can't we make TinyMCE recognize obvious Word
> crap, and then just automagically do the right thing?
>
> - the Tags/Keywords widget is still not very useable in 4.2, even though
> it has improved. But for a non-trivial site, it still sucks when a few
> hundred keywords are present. eea.tags solves this with an interface
> that "just works" for anybody who has ever used Facebook/twitter/Weibo.
> Combined, that's about 1.5 billion people. Go with the flow.
>
> - despite my trying, there is no way I can explain logically why
> NewsItems can have an image associated, and Pages dont. I routinely
> install ContentLeadImage in every site, but this seems backwards, and
> leads to user interface inconsistency. Shouldn't this be some kind of
> standard, in the future a dexterity behaviour, that integrators can
> switch on and off per contenttype?
>
> Paul Roeland
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers

On 29/08/2012, at 2:01 PM, Nathan Van Gheem wrote:

> Hi All,
>
> Eric has asked me to head up the UI team and all things improving  
> Plone's UI.
>
> Plone's user interface is starting to show it's age. Initially, the  
> main objective of the UI revamp effort will be to improve existing  
> UI failures and provide a framework to a better UI future.
>
> To tackle this, we'll focus on these things:
>
> 1) Provide obvious fixes and improvements to plone's existing UI  
> failures
> 2) Provide guidelines to developers in user testing new UI. The work  
> that martin and the developers at UCLA did is valuable in this  
> respect.
> 3) Make decisions and implement new widgets, js libraries and  
> testing infrastructure.
>
> One thing I'm not going to currently address is future deco related  
> UI concerns. That project is still cutting edge and we're not going  
> to concern too much of this effort, with the deco development. That  
> being said, deco development should adhere to decent UI guidelines  
> and many UI savvy people will be at the coming Sea Sprint.
>
> With all the said, I went through most of plone's UI and have  
> identified these issues:
>
> - content rules
>   - Confusing UI and too many page loads. Various areas this can be  
> improved.
> - folder contents
>   - drag and drop rarely works and pisses many users off, no easy  
> way to move items in a large folder. I ended up writing  
> wildcard.foldercontents to address some of these issues. If we can  
> integrate this or something similar, I think it'd be a big help.
> - widgets
>   - keyword/tag widget
>     - even the new one isn't very good. I like eea.tags or using the  
> chosen widget(
>   - date/time
>   - in and out widget
>     - one of the biggest widget failures. This could also be a  
> chosen widget. Some work to this has been played around with on  
> plone.app.widgets
>   - creators/contributors widget
>     - should be able to choose actual users, maybe display this info  
> somewhere on the content in a viewlet

I'd add the reference widget to this list.
- It's confusing with its search, select, update.
- It's not very friendly when you only have a few possibilities such  
when using a collection portlet on a small site with a few  
collections. It's not obvious you can use "*" to find all possibilities.
- it doesn't respect the navigationroot so is confusing on subsites
- it doesn't look self contained. initially it takes awhile to realise  
the search results are connected to the search box.
- doesn't give you a way to preview the items

> - Control panel
>   - could use better organization
> - users/groups control panel
>   - maybe use http://datatables.net/ or http://www.flexigrid.info/
> - html filtering
>   - terrible widgets here again...
> - types
>   - not bad but could use a bit of love
> - workflow manager
>   - plip'd for 4.3 but needs testing
>
>
> What I'm going to do now is choose items that I feel are most  
> important and start creating wireframes for them. People can comment  
> on them and suggest changes. Then I'd like to see people step up and  
> implement some of the changes as I will also be trying to do.
>
> Now, a few questions to the community.
>
> 1) What else needs help?
> 2) Who is interested in helping?
> 3) Where do we house the documentation for UI testing and  
> guidelines? David Glick suggested we just use the buildout docs: http://buildoutcoredev.readthedocs.org/en/latest/
>
>
>
> -Nathan
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond.  
> Discussions
> will include endpoint security, mobile security and the latest in  
> malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers

On Tue, Sep 11, 2012 at 11:09 AM, Roché Compaan
<roche@...> wrote:
> On Tue, Sep 11, 2012 at 8:20 AM, Dylan Jay <djay@...> wrote:
>>
>> I'd add the reference widget to this list.
>> - It's confusing with its search, select, update.
>> - It's not very friendly when you only have a few possibilities such
>> when using a collection portlet on a small site with a few
>> collections. It's not obvious you can use "*" to find all possibilities.
>> - it doesn't respect the navigationroot so is confusing on subsites
>> - it doesn't look self contained. initially it takes awhile to realise
>> the search results are connected to the search box.
>> - doesn't give you a way to preview the items
>
> I'll second this, and have time to work on this. We have made a custom
> reference widget in the past to address some of these issues,
> unfortunately too custom and not as generic as the current reference
> widget. We need to revisit this for a project that we are currently
> working on and would like to make something generally useful. If you
> have mockups to share I'm happy to work on this since it coincides
> nicely with our current project work.
>
> I'll make a few screenshots of our current widget and share them here.

Actually, if you browse to
http://www.fullmarks.org.za/@@fullmarks.theme-search-question and
click on "Select Topics", you can interact with the custom version we
developed. It has search disabled, and it doesn't allow deselecting in
the overlay but this should be an easy fix. Additionally it should be
fixed to use p.a.jquerytools overlays.

-- 
Roché Compaan
Upfront Systems                   http://www.upfrontsystems.co.za

On Tue, Sep 11, 2012 at 8:20 AM, Dylan Jay <djay@...> wrote:
>
> I'd add the reference widget to this list.
> - It's confusing with its search, select, update.
> - It's not very friendly when you only have a few possibilities such
> when using a collection portlet on a small site with a few
> collections. It's not obvious you can use "*" to find all possibilities.
> - it doesn't respect the navigationroot so is confusing on subsites
> - it doesn't look self contained. initially it takes awhile to realise
> the search results are connected to the search box.
> - doesn't give you a way to preview the items

I'll second this, and have time to work on this. We have made a custom
reference widget in the past to address some of these issues,
unfortunately too custom and not as generic as the current reference
widget. We need to revisit this for a project that we are currently
working on and would like to make something generally useful. If you
have mockups to share I'm happy to work on this since it coincides
nicely with our current project work.

I'll make a few screenshots of our current widget and share them here.

-- 
Roché Compaan
Upfront Systems                   http://www.upfrontsystems.co.za

>
> I'd add the reference widget to this list.
> - It's confusing with its search, select, update.
> - It's not very friendly when you only have a few possibilities such when
> using a collection portlet on a small site with a few collections. It's not
> obvious you can use "*" to find all possibilities.
> - it doesn't respect the navigationroot so is confusing on subsites
> - it doesn't look self contained. initially it takes awhile to realise the
> search results are connected to the search box.
> - doesn't give you a way to preview the items

Just to be sure, you're referring the formlib's reference widget correct?
The archetype widget is much improved IMO.

I very much agree with this and am also someone who has made his own custom
widget to address this in the past. Mine was just a tree widget though
which I don't think will be good enough.

To be consistent and improve it, perhaps we could just adapt
the archetypes.referencebrowserwidget to work with formlib.


On Tue, Sep 11, 2012 at 4:44 AM, Roché Compaan
<roche@...:

> On Tue, Sep 11, 2012 at 11:09 AM, Roché Compaan
> <roche@...> wrote:
> > On Tue, Sep 11, 2012 at 8:20 AM, Dylan Jay <djay@...> wrote:
> >>
> >> I'd add the reference widget to this list.
> >> - It's confusing with its search, select, update.
> >> - It's not very friendly when you only have a few possibilities such
> >> when using a collection portlet on a small site with a few
> >> collections. It's not obvious you can use "*" to find all possibilities.
> >> - it doesn't respect the navigationroot so is confusing on subsites
> >> - it doesn't look self contained. initially it takes awhile to realise
> >> the search results are connected to the search box.
> >> - doesn't give you a way to preview the items
> >
> > I'll second this, and have time to work on this. We have made a custom
> > reference widget in the past to address some of these issues,
> > unfortunately too custom and not as generic as the current reference
> > widget. We need to revisit this for a project that we are currently
> > working on and would like to make something generally useful. If you
> > have mockups to share I'm happy to work on this since it coincides
> > nicely with our current project work.
> >
> > I'll make a few screenshots of our current widget and share them here.
>
> Actually, if you browse to
> http://www.fullmarks.org.za/@@fullmarks.theme-search-question and
> click on "Select Topics", you can interact with the custom version we
> developed. It has search disabled, and it doesn't allow deselecting in
> the overlay but this should be an easy fix. Additionally it should be
> fixed to use p.a.jquerytools overlays.
>
> --
> Roché Compaan
> Upfront Systems                   http://www.upfrontsystems.co.za
>

On 11/09/2012, at 11:54 PM, Nathan Van Gheem wrote:

> I'd add the reference widget to this list.
> - It's confusing with its search, select, update.
> - It's not very friendly when you only have a few possibilities such  
> when using a collection portlet on a small site with a few  
> collections. It's not obvious you can use "*" to find all  
> possibilities.
> - it doesn't respect the navigationroot so is confusing on subsites
> - it doesn't look self contained. initially it takes awhile to  
> realise the search results are connected to the search box.
> - doesn't give you a way to preview the items
> Just to be sure, you're referring the formlib's reference widget  
> correct? The archetype widget is much improved IMO.
>
> I very much agree with this and am also someone who has made his own  
> custom widget to address this in the past. Mine was just a tree  
> widget though which I don't think will be good enough.
>
> To be consistent and improve it, perhaps we could just adapt the  
> archetypes.referencebrowserwidget to work with formlib.

it used to be bad too, using a new browser window and used to not have  
it's css attached for some reason but you're right it's much better now.
Roche's version is nice too and similar but the new AT version is  
nicer. It would be a quick win to replace the formlib widget with the  
AT one.

Is it feasible to have a single referencebrowser that's used  
everywhere? tinymce images & links, formlib, zc3form and AT.
CMSUI had the nice github like scrolling content browser. It would be  
plus if improvements like that made once are used everywhere.
Other improvements I can think of off teh top of my head are recently  
visited folders, previews of items, favourite folders and perhaps a  
dropdown breadcrumb like osx has as it takes less space when the tree  
is deep.


>
>
> On Tue, Sep 11, 2012 at 4:44 AM, Roché Compaan <roche@... 
> > wrote:
> On Tue, Sep 11, 2012 at 11:09 AM, Roché Compaan
> <roche@...> wrote:
> > On Tue, Sep 11, 2012 at 8:20 AM, Dylan Jay <djay@...>  
> wrote:
> >>
> >> I'd add the reference widget to this list.
> >> - It's confusing with its search, select, update.
> >> - It's not very friendly when you only have a few possibilities  
> such
> >> when using a collection portlet on a small site with a few
> >> collections. It's not obvious you can use "*" to find all  
> possibilities.
> >> - it doesn't respect the navigationroot so is confusing on subsites
> >> - it doesn't look self contained. initially it takes awhile to  
> realise
> >> the search results are connected to the search box.
> >> - doesn't give you a way to preview the items
> >
> > I'll second this, and have time to work on this. We have made a  
> custom
> > reference widget in the past to address some of these issues,
> > unfortunately too custom and not as generic as the current reference
> > widget. We need to revisit this for a project that we are currently
> > working on and would like to make something generally useful. If you
> > have mockups to share I'm happy to work on this since it coincides
> > nicely with our current project work.
> >
> > I'll make a few screenshots of our current widget and share them  
> here.
>
> Actually, if you browse to
> http://www.fullmarks.org.za/@@fullmarks.theme-search-question and
> click on "Select Topics", you can interact with the custom version we
> developed. It has search disabled, and it doesn't allow deselecting in
> the overlay but this should be an easy fix. Additionally it should be
> fixed to use p.a.jquerytools overlays.
>
> --
> Roché Compaan
> Upfront Systems                   http://www.upfrontsystems.co.za
>

On 12/09/2012, at 12:58 AM, Dylan Jay <djay@...> wrote:

>
> On 11/09/2012, at 11:54 PM, Nathan Van Gheem wrote:
>
>> I'd add the reference widget to this list.
>> - It's confusing with its search, select, update.
>> - It's not very friendly when you only have a few possibilities such when using a collection portlet on a small site with a few collections. It's not obvious you can use "*" to find all possibilities.
>> - it doesn't respect the navigationroot so is confusing on subsites
>> - it doesn't look self contained. initially it takes awhile to realise the search results are connected to the search box.
>> - doesn't give you a way to preview the items
>> Just to be sure, you're referring the formlib's reference widget correct? The archetype widget is much improved IMO.
>>
>> I very much agree with this and am also someone who has made his own custom widget to address this in the past. Mine was just a tree widget though which I don't think will be good enough.
>>
>> To be consistent and improve it, perhaps we could just adapt the archetypes.referencebrowserwidget to work with formlib.
>
> it used to be bad too, using a new browser window and used to not have it's css attached for some reason but you're right it's much better now.
> Roche's version is nice too and similar but the new AT version is nicer. It would be a quick win to replace the formlib widget with the AT one.
>
> Is it feasible to have a single referencebrowser that's used everywhere? tinymce images & links, formlib, zc3form and AT.
> CMSUI had the nice github like scrolling content browser. It would be plus if improvements like that made once are used everywhere.
> Other improvements I can think of off teh top of my head are recently visited folders, previews of items, favourite folders and perhaps a dropdown breadcrumb like osx has as it takes less space when the tree is deep.

Another UI annoyance.
Just looking at a customer request to "approve all news items in one go".
Collections provide a nice way to do this. Create a collection with
the right criteria, click contents, select all and then change state.
Annoyance is that it's unintuitive to create content to do an
administrative function and it's cumbersome for adhoc queries.
With 4.2 we have query string UI separated from collections and with
Plone.app.toolbar we will have a content browser overlay separated
from the current content. If the user can do adhoc collection like
queries inside this content browser overlay and then select all and do
cut copy, change state etc, that would be very convenient. If they can
also save those queries for later use too kind of like how you can
make smart folders in Mac.mail. And lastly if there was a combined
toolbar content browser and form referencebrowser widget you'd be able
to do all those saved queries when picking images or in portlets. That
would be a big productivity boost.




>
>
>>
>>
>> On Tue, Sep 11, 2012 at 4:44 AM, Roché Compaan <roche@...> wrote:
>> On Tue, Sep 11, 2012 at 11:09 AM, Roché Compaan
>> <roche@...> wrote:
>> > On Tue, Sep 11, 2012 at 8:20 AM, Dylan Jay <djay@...> wrote:
>> >>
>> >> I'd add the reference widget to this list.
>> >> - It's confusing with its search, select, update.
>> >> - It's not very friendly when you only have a few possibilities such
>> >> when using a collection portlet on a small site with a few
>> >> collections. It's not obvious you can use "*" to find all possibilities.
>> >> - it doesn't respect the navigationroot so is confusing on subsites
>> >> - it doesn't look self contained. initially it takes awhile to realise
>> >> the search results are connected to the search box.
>> >> - doesn't give you a way to preview the items
>> >
>> > I'll second this, and have time to work on this. We have made a custom
>> > reference widget in the past to address some of these issues,
>> > unfortunately too custom and not as generic as the current reference
>> > widget. We need to revisit this for a project that we are currently
>> > working on and would like to make something generally useful. If you
>> > have mockups to share I'm happy to work on this since it coincides
>> > nicely with our current project work.
>> >
>> > I'll make a few screenshots of our current widget and share them here.
>>
>> Actually, if you browse to
>> http://www.fullmarks.org.za/@@fullmarks.theme-search-question and
>> click on "Select Topics", you can interact with the custom version we
>> developed. It has search disabled, and it doesn't allow deselecting in
>> the overlay but this should be an easy fix. Additionally it should be
>> fixed to use p.a.jquerytools overlays.
>>
>> --
>> Roché Compaan
>> Upfront Systems                   http://www.upfrontsystems.co.za
>>
>

Am 12.09.2012 um 06:22 schrieb Dylan Jay:

> Another UI annoyance.
> Just looking at a customer request to "approve all news items in one  
> go".
> Collections provide a nice way to do this. Create a collection with
> the right criteria, click contents, select all and then change state.
> Annoyance is that it's unintuitive to create content to do an
> administrative function and it's cumbersome for adhoc queries.
> With 4.2 we have query string UI separated from collections and with
> Plone.app.toolbar we will have a content browser overlay separated
> from the current content. If the user can do adhoc collection like
> queries inside this content browser overlay and then select all and do
> cut copy, change state etc, that would be very convenient. If they can
> also save those queries for later use too kind of like how you can
> make smart folders in Mac.mail.

There was a talk on a tool aiming at similar stuff during the DZUG  
conference 2009 in Munich by Maik Derstappen.

Startpoint
http://plone.org/products/inqbus.plone.clipboard

PDF of the Talk slides (german only):
http://old.zope.de/redaktion/dzug/tagung/2009/die-vortraege/clipboard-fuer-plone.pdf

> And lastly if there was a combined
> toolbar content browser and form referencebrowser widget you'd be able
> to do all those saved queries when picking images or in portlets. That
> would be a big productivity boost.

To integrate this in the UI you need a low footprint  representation.

"Action splash overlay" , invoked by touchable marker (e.g. "the  
little pencil")

I discussed some "Action splash overlay" for speeding up tasks without  
bloating the UI with Maik and Timo Stollenwerk during FrOSCon  
conference. This aims at minimizing the mouse traffic to the toolbar,  
that can annoy a lot with cmsui. The actions are an icon based  
contextual menu, done as an overlay, feeded from the portal-action  
(icons) with a new category. The splash menu can be invoked even on  
touch displays by providing a low footprint marker, next to the topic  
to be edited. We thought to make a quick & dirty prototype to get  
feedback from users. More (e.g. radial menu)  if I find the time.

Armin

--
Armin Carl Stroß-Radschinski, Dipl. Designer
acsr industrialdesign, Landgrafenstraße 32, 53842 Troisdorf, Germany

Telefon +49 (0) 22 41 / 94 69 94, FAX +49 (0) 22 41 / 94 69 96
eMail a.stross-radschinski@... - http://www.acsr.de
UST. ID Nr: DE154092803 (EU VAT ID)

On 12/09/2012, at 4:00 PM, Armin Stroß-Radschinski wrote:

> Am 12.09.2012 um 06:22 schrieb Dylan Jay:
>
>> Another UI annoyance.
>> Just looking at a customer request to "approve all news items in  
>> one go".
>> Collections provide a nice way to do this. Create a collection with
>> the right criteria, click contents, select all and then change state.
>> Annoyance is that it's unintuitive to create content to do an
>> administrative function and it's cumbersome for adhoc queries.
>> With 4.2 we have query string UI separated from collections and with
>> Plone.app.toolbar we will have a content browser overlay separated
>> from the current content. If the user can do adhoc collection like
>> queries inside this content browser overlay and then select all and  
>> do
>> cut copy, change state etc, that would be very convenient. If they  
>> can
>> also save those queries for later use too kind of like how you can
>> make smart folders in Mac.mail.
>
> There was a talk on a tool aiming at similar stuff during the DZUG  
> conference 2009 in Munich by Maik Derstappen.
>
> Startpoint
> http://plone.org/products/inqbus.plone.clipboard
>
> PDF of the Talk slides (german only):
> http://old.zope.de/redaktion/dzug/tagung/2009/die-vortraege/clipboard-fuer-plone.pdf

thats a different but related idea I think.
I was suggesting building canned queries into the content browser, ie  
to bring into a single listing so you can do things to them at once
That talk is about selecting content from around the site arbitrarily  
and bringing them together like in a shopping cart so you can do  
things in bulk to them.
Both are good ideas with slightly different use cases.

>
>> And lastly if there was a combined
>> toolbar content browser and form referencebrowser widget you'd be  
>> able
>> to do all those saved queries when picking images or in portlets.  
>> That
>> would be a big productivity boost.
>
> To integrate this in the UI you need a low footprint  representation.
>
> "Action splash overlay" , invoked by touchable marker (e.g. "the  
> little pencil")
>
> I discussed some "Action splash overlay" for speeding up tasks  
> without bloating the UI with Maik and Timo Stollenwerk during  
> FrOSCon conference. This aims at minimizing the mouse traffic to the  
> toolbar, that can annoy a lot with cmsui. The actions are an icon  
> based contextual menu, done as an overlay, feeded from the portal- 
> action (icons) with a new category. The splash menu can be invoked  
> even on touch displays by providing a low footprint marker, next to  
> the topic to be edited. We thought to make a quick & dirty prototype  
> to get feedback from users. More (e.g. radial menu)  if I find the  
> time.

I'm not sure what a "Action splash overlay" is or where it might popup.

I was thinking the plone.app.toolbar could work a bit more like the  
image dialog used to in kupu with quick canned queries on the left.  
Only difference is that user would be able to add more queries if they  
wanted or do an ad hoc query.

Am 12.09.2012 um 09:24 schrieb Dylan Jay:

> On 12/09/2012, at 4:00 PM, Armin Stroß-Radschinski wrote:
>
>> Am 12.09.2012 um 06:22 schrieb Dylan Jay:
>>
>>> Another UI annoyance.
>>> Just looking at a customer request to "approve all news items in  
>>> one go".
>>> Collections provide a nice way to do this. Create a collection with
>>> the right criteria, click contents, select all and then change  
>>> state.
>>> Annoyance is that it's unintuitive to create content to do an
>>> administrative function and it's cumbersome for adhoc queries.
>>> With 4.2 we have query string UI separated from collections and with
>>> Plone.app.toolbar we will have a content browser overlay separated
>>> from the current content. If the user can do adhoc collection like
>>> queries inside this content browser overlay and then select all  
>>> and do
>>> cut copy, change state etc, that would be very convenient. If they  
>>> can
>>> also save those queries for later use too kind of like how you can
>>> make smart folders in Mac.mail.
>>
>> There was a talk on a tool aiming at similar stuff during the DZUG  
>> conference 2009 in Munich by Maik Derstappen.
>>
>> Startpoint
>> http://plone.org/products/inqbus.plone.clipboard
>>
>> PDF of the Talk slides (german only):
>> http://old.zope.de/redaktion/dzug/tagung/2009/die-vortraege/clipboard-fuer-plone.pdf
>
(Please forgive that I just jumped in without reading the whole thread)
> thats a different but related idea I think.
> I was suggesting building canned queries into the content browser,  
> ie to bring into a single listing so you can do things to them at once
> That talk is about selecting content from around the site  
> arbitrarily and bringing them together like in a shopping cart so  
> you can do things in bulk to them.
> Both are good ideas with slightly different use cases.

If you can use live filters on content and apply an global action is  
cool for all adminstrative tasks. So the interface itsself  should not  
constrain to certain actions. Why limiting the use, when the user can  
do the same one by one by hand.

How does complexity grow in Plone if you provide this feature?

There are risks on the second view. The main risk is great mess  
instead of some mess ;-) So making an transaction out of all triggered  
actions is wise, but may not be the only option (admin option:  
complete even if errors come up on certain objects).

One other challenge is to apply some checking if action are suitable  
(or allowed) for mass operations from the UI. So complexity grows if  
you need to "ghost" those options and so on.

>>
>>> And lastly if there was a combined
>>> toolbar content browser and form referencebrowser widget you'd be  
>>> able
>>> to do all those saved queries when picking images or in portlets.  
>>> That
>>> would be a big productivity boost.
>>
>> To integrate this in the UI you need a low footprint  representation.
>>
>> "Action splash overlay" , invoked by touchable marker (e.g. "the  
>> little pencil")
>>
>> I discussed some "Action splash overlay" for speeding up tasks  
>> without bloating the UI with Maik and Timo Stollenwerk during  
>> FrOSCon conference. This aims at minimizing the mouse traffic to  
>> the toolbar, that can annoy a lot with cmsui. The actions are an  
>> icon based contextual menu, done as an overlay, feeded from the  
>> portal-action (icons) with a new category. The splash menu can be  
>> invoked even on touch displays by providing a low footprint marker,  
>> next to the topic to be edited. We thought to make a quick & dirty  
>> prototype to get feedback from users. More (e.g. radial menu)  if I  
>> find the time.
>
> I'm not sure what a "Action splash overlay" is or where it might  
> popup.

I am not aiming at the stuff below. May I did not get the point at  
once ...

There are a lot of productivity flaws we could improve by simple UI  
changes.
I was just reading "approving a list in one go..."  and I also often  
need to edit a lot of objects from the content listing. This currently  
needs two clicks and an inbetween page load.

If we can add an optional "editors_productivity_listing_view" to  
collections (folderish objects!), that would be great. To make this an  
overlay was not originally intended by my "Action Splash overlay", but  
you inspired me now to that.


(The pencil icon from the contents listing (for external edit) is gone  
in Plone for a long time. I missed this and added it when needed by  
myself. I did not check if Option-Clicking is suitable in the browser  
for that. This could be part of this UI as well. )

> I was thinking the plone.app.toolbar could work a bit more like the  
> image dialog used to in kupu with quick canned queries on the left.  
> Only difference is that user would be able to add more queries if  
> they wanted or do an ad hoc query.
>
> <pastedGraphic.tiff>

If I get the point now, that idea is cool because you get search AND  
actions / options for a selection without leaving the page. If you  
want to concatenate multiple actions before you leave the overlay, a  
little textbased stack
  with logging the preselected actions and then the execution (similar  
to Quick-Upload) will be helpful.
>>
>> Armin


Armin
--
Armin Carl Stroß-Radschinski, Dipl. Designer
acsr industrialdesign, Landgrafenstraße 32, 53842 Troisdorf, Germany

Telefon +49 (0) 22 41 / 94 69 94, FAX +49 (0) 22 41 / 94 69 96
eMail a.stross-radschinski@... - http://www.acsr.de
UST. ID Nr: DE154092803 (EU VAT ID)

On 07/09/12 20:48, Elizabeth Leddy wrote:
>>> - the Tags/Keywords widget is still not very useable in 4.2, even though
>>> it has improved. But for a non-trivial site, it still sucks when a few
>>> hundred keywords are present. eea.tags solves this with an interface
>>> that "just works" for anybody who has ever used Facebook/twitter/Weibo.
>>> Combined, that's about 1.5 billion people. Go with the flow.
>>
>> +1 for a better widget, as long as it remains accessible, which was a
>> key goal of the current widget.
>
> Please, please someone plip this....

we made some work on this and other widgets in 
https://github.com/collective/collective.z3cform.widgets

it's for z3c.form, it has screenshots, has been on production for a 
while and probably can be used as an starting point even as 
https://github.com/collective/eea.tags seems to be more optimized.

I would prefer to move this discussion to a different media, because 
email is not really good for managing brainstorming.

what about http://www.mindmeister.com/ or something similar?

best regards

ps: the screenshot for EnhancedTextLinesFieldWidget is not updated and 
it's even better now: you can edit, delete and change the order of the 
lines; alse seems that I need to add a screenshot for the 
MultiContentSearchFieldWidget... I'll try to do it later.

hi (and forgive me for not having read all the posts)

Den 12. sep. 2012 kl. 06.23 skrev Dylan Jay [via Plone]:

> On 12/09/2012, at 12:58 AM, Dylan Jay <[hidden email]> wrote: 
> 
> > 
> > On 11/09/2012, at 11:54 PM, Nathan Van Gheem wrote: 
> > 
> >> I'd add the reference widget to this list. 
> >> - It's confusing with its search, select, update. 
> >> - It's not very friendly when you only have a few possibilities such when using a collection portlet on a small site with a few collections. It's not obvious you can use "*" to find all possibilities. 
> >> - it doesn't respect the navigationroot so is confusing on subsites 
> >> - it doesn't look self contained. initially it takes awhile to realise the search results are connected to the search box. 
> >> - doesn't give you a way to preview the items 
> >> Just to be sure, you're referring the formlib's reference widget correct? The archetype widget is much improved IMO. 
> >> 
> >> I very much agree with this and am also someone who has made his own custom widget to address this in the past. Mine was just a tree widget though which I don't think will be good enough. 
> >> 
> >> To be consistent and improve it, perhaps we could just adapt the archetypes.referencebrowserwidget to work with formlib. 
> > 
> > it used to be bad too, using a new browser window and used to not have it's css attached for some reason but you're right it's much better now. 
> > Roche's version is nice too and similar but the new AT version is nicer. It would be a quick win to replace the formlib widget with the AT one. 
> > 
> > Is it feasible to have a single referencebrowser that's used everywhere? tinymce images & links, formlib, zc3form and AT. 
> > CMSUI had the nice github like scrolling content browser. It would be plus if improvements like that made once are used everywhere. 
> > Other improvements I can think of off teh top of my head are recently visited folders, previews of items, favourite folders and perhaps a dropdown breadcrumb like osx has as it takes less space when the tree is deep.
> 
> Another UI annoyance. 
> Just looking at a customer request to "approve all news items in one go". 
> Collections provide a nice way to do this. Create a collection with 
> the right criteria, click contents, select all and then change state. 

What if it was possible to do this from search results, in other words:
if it was possible to show a "normal" search as "folder contents".
(maybe a link on the normal "results page")

Espen


> Annoyance is that it's unintuitive to create content to do an 
> administrative function and it's cumbersome for adhoc queries. 
> With 4.2 we have query string UI separated from collections and with 
> Plone.app.toolbar we will have a content browser overlay separated 
> from the current content. If the user can do adhoc collection like 
> queries inside this content browser overlay and then select all and do 
> cut copy, change state etc, that would be very convenient. If they can 
> also save those queries for later use too kind of like how you can 
> make smart folders in Mac.mail. And lastly if there was a combined 
> toolbar content browser and form referencebrowser widget you'd be able 
> to do all those saved queries when picking images or in portlets. That 
> would be a big productivity boost. 
> 
> 
> 
> 
> > 
> > 
> >> 
> >> 
> >> On Tue, Sep 11, 2012 at 4:44 AM, Roché Compaan <[hidden email]> wrote: 
> >> On Tue, Sep 11, 2012 at 11:09 AM, Roché Compaan 
> >> <[hidden email]> wrote: 
> >> > On Tue, Sep 11, 2012 at 8:20 AM, Dylan Jay <[hidden email]> wrote: 
> >> >> 
> >> >> I'd add the reference widget to this list. 
> >> >> - It's confusing with its search, select, update. 
> >> >> - It's not very friendly when you only have a few possibilities such 
> >> >> when using a collection portlet on a small site with a few 
> >> >> collections. It's not obvious you can use "*" to find all possibilities. 
> >> >> - it doesn't respect the navigationroot so is confusing on subsites 
> >> >> - it doesn't look self contained. initially it takes awhile to realise 
> >> >> the search results are connected to the search box. 
> >> >> - doesn't give you a way to preview the items 
> >> > 
> >> > I'll second this, and have time to work on this. We have made a custom 
> >> > reference widget in the past to address some of these issues, 
> >> > unfortunately too custom and not as generic as the current reference 
> >> > widget. We need to revisit this for a project that we are currently 
> >> > working on and would like to make something generally useful. If you 
> >> > have mockups to share I'm happy to work on this since it coincides 
> >> > nicely with our current project work. 
> >> > 
> >> > I'll make a few screenshots of our current widget and share them here. 
> >> 
> >> Actually, if you browse to 
> >> http://www.fullmarks.org.za/@@fullmarks.theme-search-question and 
> >> click on "Select Topics", you can interact with the custom version we 
> >> developed. It has search disabled, and it doesn't allow deselecting in 
> >> the overlay but this should be an easy fix. Additionally it should be 
> >> fixed to use p.a.jquerytools overlays. 
> >> 
> >> -- 
> >> Roché Compaan 
> >> Upfront Systems                   http://www.upfrontsystems.co.za
> >> 
> >
> 
> ------------------------------------------------------------------------------ 
> Live Security Virtual Conference 
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________ 
> Plone-developers mailing list 
> [hidden email] 
> https://lists.sourceforge.net/lists/listinfo/plone-developers
> 
> 
> If you reply to this email, your message will be added to the discussion below:
> http://plone.293351.n2.nabble.com/Time-to-improve-plone-s-UI-tp7558413p7558913.html
> To unsubscribe from Plone, click here.
> NAML





--
View this message in context: http://plone.293351.n2.nabble.com/Time-to-improve-plone-s-UI-tp7558413p7559017.html
Sent from the Core Developers mailing list archive at Nabble.com.

On 14/09/2012, at 11:21 PM, espen wrote:

> hi (and forgive me for not having read all the posts)
>
> Den 12. sep. 2012 kl. 06.23 skrev Dylan Jay [via Plone]:
>
>> On 12/09/2012, at 12:58 AM, Dylan Jay <<a href="x-msg://709/user/ 
>> SendEmail.jtp?type=node&amp;node=7558913&amp;i=0" target="_top"  
>> rel="nofollow" link="external">[hidden email]> wrote:
>>
>> >
>> > On 11/09/2012, at 11:54 PM, Nathan Van Gheem wrote:
>> >
>> >> I'd add the reference widget to this list.
>> >> - It's confusing with its search, select, update.
>> >> - It's not very friendly when you only have a few possibilities  
>> such when using a collection portlet on a small site with a few  
>> collections. It's not obvious you can use "*" to find all  
>> possibilities.
>> >> - it doesn't respect the navigationroot so is confusing on  
>> subsites
>> >> - it doesn't look self contained. initially it takes awhile to  
>> realise the search results are connected to the search box.
>> >> - doesn't give you a way to preview the items
>> >> Just to be sure, you're referring the formlib's reference widget  
>> correct? The archetype widget is much improved IMO.
>> >>
>> >> I very much agree with this and am also someone who has made his  
>> own custom widget to address this in the past. Mine was just a tree  
>> widget though which I don't think will be good enough.
>> >>
>> >> To be consistent and improve it, perhaps we could just adapt the  
>> archetypes.referencebrowserwidget to work with formlib.
>> >
>> > it used to be bad too, using a new browser window and used to not  
>> have it's css attached for some reason but you're right it's much  
>> better now.
>> > Roche's version is nice too and similar but the new AT version is  
>> nicer. It would be a quick win to replace the formlib widget with  
>> the AT one.
>> >
>> > Is it feasible to have a single referencebrowser that's used  
>> everywhere? tinymce images & links, formlib, zc3form and AT.
>> > CMSUI had the nice github like scrolling content browser. It  
>> would be plus if improvements like that made once are used  
>> everywhere.
>> > Other improvements I can think of off teh top of my head are  
>> recently visited folders, previews of items, favourite folders and  
>> perhaps a dropdown breadcrumb like osx has as it takes less space  
>> when the tree is deep.
>> Another UI annoyance.
>> Just looking at a customer request to "approve all news items in  
>> one go".
>> Collections provide a nice way to do this. Create a collection with
>> the right criteria, click contents, select all and then change state.
>
> What if it was possible to do this from search results, in other  
> words:
> if it was possible to show a "normal" search as "folder contents".
> (maybe a link on the normal "results page")

That's more or less the idea except this is inside plone.app.toolbar  
browser pane, or inside a content selection widget (referencebrowser  
widget).

I think I need to mock it up. Much more effective than words :)


>
> Espen
>
>
>> Annoyance is that it's unintuitive to create content to do an
>> administrative function and it's cumbersome for adhoc queries.
>> With 4.2 we have query string UI separated from collections and with
>> Plone.app.toolbar we will have a content browser overlay separated
>> from the current content. If the user can do adhoc collection like
>> queries inside this content browser overlay and then select all and  
>> do
>> cut copy, change state etc, that would be very convenient. If they  
>> can
>> also save those queries for later use too kind of like how you can
>> make smart folders in Mac.mail. And lastly if there was a combined
>> toolbar content browser and form referencebrowser widget you'd be  
>> able
>> to do all those saved queries when picking images or in portlets.  
>> That
>> would be a big productivity boost.
>>
>>
>>
>>
>> >
>> >
>> >>
>> >>
>> >> On Tue, Sep 11, 2012 at 4:44 AM, Roché Compaan <<a href="x- 
>> msg://709/user/SendEmail.jtp?type=node&amp;node=7558913&amp;i=1"  
>> target="_top" rel="nofollow" link="external">[hidden email]> wrote:
>> >> On Tue, Sep 11, 2012 at 11:09 AM, Roché Compaan
>> >> <<a href="x-msg://709/user/SendEmail.jtp? 
>> type=node&amp;node=7558913&amp;i=2" target="_top" rel="nofollow"  
>> link="external">[hidden email]> wrote:
>> >> > On Tue, Sep 11, 2012 at 8:20 AM, Dylan Jay <<a href="x-msg:// 
>> 709/user/SendEmail.jtp?type=node&amp;node=7558913&amp;i=3"  
>> target="_top" rel="nofollow" link="external">[hidden email]> wrote:
>> >> >>
>> >> >> I'd add the reference widget to this list.
>> >> >> - It's confusing with its search, select, update.
>> >> >> - It's not very friendly when you only have a few  
>> possibilities such
>> >> >> when using a collection portlet on a small site with a few
>> >> >> collections. It's not obvious you can use "*" to find all  
>> possibilities.
>> >> >> - it doesn't respect the navigationroot so is confusing on  
>> subsites
>> >> >> - it doesn't look self contained. initially it takes awhile  
>> to realise
>> >> >> the search results are connected to the search box.
>> >> >> - doesn't give you a way to preview the items
>> >> >
>> >> > I'll second this, and have time to work on this. We have made  
>> a custom
>> >> > reference widget in the past to address some of these issues,
>> >> > unfortunately too custom and not as generic as the current  
>> reference
>> >> > widget. We need to revisit this for a project that we are  
>> currently
>> >> > working on and would like to make something generally useful.  
>> If you
>> >> > have mockups to share I'm happy to work on this since it  
>> coincides
>> >> > nicely with our current project work.
>> >> >
>> >> > I'll make a few screenshots of our current widget and share  
>> them here.
>> >>
>> >> Actually, if you browse to
>> >> http://www.fullmarks.org.za/@@fullmarks.theme-search-question and
>> >> click on "Select Topics", you can interact with the custom  
>> version we
>> >> developed. It has search disabled, and it doesn't allow  
>> deselecting in
>> >> the overlay but this should be an easy fix. Additionally it  
>> should be
>> >> fixed to use p.a.jquerytools overlays.
>> >>
>> >> --
>> >> Roché Compaan
>> >> Upfront Systems                   http://www.upfrontsystems.co.za
>> >>
>> >
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.  
>> Discussions
>> will include endpoint security, mobile security and the latest in  
>> malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Plone-developers mailing list
>> <a href="x-msg://709/user/SendEmail.jtp? 
>> type=node&amp;node=7558913&amp;i=4" target="_top" rel="nofollow"  
>> link="external">[hidden email]
>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>>
>>
>> If you reply to this email, your message will be added to the  
>> discussion below:
>> http://plone.293351.n2.nabble.com/Time-to-improve-plone-s-UI-tp7558413p7558913.html
>> To unsubscribe from Plone, click here.
>> NAML
>
>
> View this message in context: Re: Time to improve plone's UI
> Sent from the Core Developers mailing list archive at Nabble.com.
> ------------------------------------------------------------------------------
> Got visibility?
> Most devs has no idea what their production app looks like.
> Find out how fast your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219671;13503038;y?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html_______________________________________________
> Plone-developers mailing list
> Plone-developers@...
> https://lists.sourceforge.net/lists/listinfo/plone-developers

On 12/09/2012, at 8:12 PM, Armin Stroß-Radschinski wrote:

>
> Am 12.09.2012 um 09:24 schrieb Dylan Jay:
>
>> On 12/09/2012, at 4:00 PM, Armin Stroß-Radschinski wrote:
>>
>>> Am 12.09.2012 um 06:22 schrieb Dylan Jay:
>>>
>>>> Another UI annoyance.
>>>> Just looking at a customer request to "approve all news items in  
>>>> one go".
>>>> Collections provide a nice way to do this. Create a collection with
>>>> the right criteria, click contents, select all and then change  
>>>> state.
>>>> Annoyance is that it's unintuitive to create content to do an
>>>> administrative function and it's cumbersome for adhoc queries.
>>>> With 4.2 we have query string UI separated from collections and  
>>>> with
>>>> Plone.app.toolbar we will have a content browser overlay separated
>>>> from the current content. If the user can do adhoc collection like
>>>> queries inside this content browser overlay and then select all  
>>>> and do
>>>> cut copy, change state etc, that would be very convenient. If  
>>>> they can
>>>> also save those queries for later use too kind of like how you can
>>>> make smart folders in Mac.mail.
>>>
>>> There was a talk on a tool aiming at similar stuff during the DZUG  
>>> conference 2009 in Munich by Maik Derstappen.
>>>
>>> Startpoint
>>> http://plone.org/products/inqbus.plone.clipboard
>>>
>>> PDF of the Talk slides (german only):
>>> http://old.zope.de/redaktion/dzug/tagung/2009/die-vortraege/clipboard-fuer-plone.pdf
>>
> (Please forgive that I just jumped in without reading the whole  
> thread)
>> thats a different but related idea I think.
>> I was suggesting building canned queries into the content browser,  
>> ie to bring into a single listing so you can do things to them at  
>> once
>> That talk is about selecting content from around the site  
>> arbitrarily and bringing them together like in a shopping cart so  
>> you can do things in bulk to them.
>> Both are good ideas with slightly different use cases.
>
> If you can use live filters on content and apply an global action is  
> cool for all adminstrative tasks. So the interface itsself  should  
> not constrain to certain actions. Why limiting the use, when the  
> user can do the same one by one by hand.
>
> How does complexity grow in Plone if you provide this feature?
>
> There are risks on the second view. The main risk is great mess  
> instead of some mess ;-) So making an transaction out of all  
> triggered actions is wise, but may not be the only option (admin  
> option: complete even if errors come up on certain objects).
>
> One other challenge is to apply some checking if action are suitable  
> (or allowed) for mass operations from the UI. So complexity grows if  
> you need to "ghost" those options and so on.

the languange barrier is getting in the way somewhat I think.

What I think you are saying is that if bulk operations are allowed  
then why restrict it to just copy, cut and change state? Yes you could  
extend it to more actions such as dynamic display etc, but as you  
point out we'd have to have a lot more plumbing to be able to show the  
correct options or perform the right action if the items of different  
types, in different folders. One step at a time :) Since some of those  
actions are changing with deco maybe now is not the time.


>
>>>
>>>> And lastly if there was a combined
>>>> toolbar content browser and form referencebrowser widget you'd be  
>>>> able
>>>> to do all those saved queries when picking images or in portlets.  
>>>> That
>>>> would be a big productivity boost.
>>>
>>> To integrate this in the UI you need a low footprint   
>>> representation.
>>>
>>> "Action splash overlay" , invoked by touchable marker (e.g. "the  
>>> little pencil")
>>>
>>> I discussed some "Action splash overlay" for speeding up tasks  
>>> without bloating the UI with Maik and Timo Stollenwerk during  
>>> FrOSCon conference. This aims at minimizing the mouse traffic to  
>>> the toolbar, that can annoy a lot with cmsui. The actions are an  
>>> icon based contextual menu, done as an overlay, feeded from the  
>>> portal-action (icons) with a new category. The splash menu can be  
>>> invoked even on touch displays by providing a low footprint  
>>> marker, next to the topic to be edited. We thought to make a quick  
>>> & dirty prototype to get feedback from users. More (e.g. radial  
>>> menu)  if I find the time.
>>
>> I'm not sure what a "Action splash overlay" is or where it might  
>> popup.
>
> I am not aiming at the stuff below. May I did not get the point at  
> once ...
>
> There are a lot of productivity flaws we could improve by simple UI  
> changes.
> I was just reading "approving a list in one go..."  and I also often  
> need to edit a lot of objects from the content listing. This  
> currently needs two clicks and an inbetween page load.
>
> If we can add an optional "editors_productivity_listing_view" to  
> collections (folderish objects!), that would be great. To make this  
> an overlay was not originally intended by my "Action Splash  
> overlay", but you inspired me now to that.
>
>
> (The pencil icon from the contents listing (for external edit) is  
> gone in Plone for a long time. I missed this and added it when  
> needed by myself. I did not check if Option-Clicking is suitable in  
> the browser for that. This could be part of this UI as well. )
>
>> I was thinking the plone.app.toolbar could work a bit more like the  
>> image dialog used to in kupu with quick canned queries on the left.  
>> Only difference is that user would be able to add more queries if  
>> they wanted or do an ad hoc query.
>>
>> <pastedGraphic.tiff>
>
> If I get the point now, that idea is cool because you get search AND  
> actions / options for a selection without leaving the page. If you  
> want to concatenate multiple actions before you leave the overlay, a  
> little textbased stack
> with logging the preselected actions and then the execution (similar  
> to Quick-Upload) will be helpful.
>>>
>>> Armin
>
>
> Armin
> --
> Armin Carl Stroß-Radschinski, Dipl. Designer
> acsr industrialdesign, Landgrafenstraße 32, 53842 Troisdorf, Germany
>
> Telefon +49 (0) 22 41 / 94 69 94, FAX +49 (0) 22 41 / 94 69 96
> eMail a.stross-radschinski@... - http://www.acsr.de
> UST. ID Nr: DE154092803 (EU VAT ID)
>
>
>
>