Created attachment 111930 [details]
First rough mockup
I am approaching this issue from two views. The first is that we have 800 users and I have monitored the support calls and am aware of the problems users are having with the picker. I also would like to see better CMIS support implemented to allow for searches. In our case, CMIS is Alfresco. Currently users would have to log into the web interface of Alfresco to find a document, and then use LibreOffice to locate that document within the virtual file structure.
I have created a mockup with what I perceive to be the shortcomings/problems, along with my feature requests. Very likely this will have to be split into multiple requests, but I am initiating contact with the UX professionals. I'm sure someone can make a nicer mockup.
** The top area is the "path" and it's not marked as such, and users don't understand the difference between path and file name.
** Advanced users would love to be able to type in the full path and also file name into the top area -- right now you have to type in the path first and then click into the file area and type in the file name.
** A search box is a feature request, and based on backend would have different functionality. Possibly that would be:
-- CMIS: search the backend datastore for matching keywords, tags and contents that match the search criteria.
--- Linux: possibly tracker would be queried
--- All platforms on local file system, possibly a simple search of file names *<search_criteria>.* to reduce the displayed files.
** The left area should be changed to "Favorites" and allow for more options instead of just allowing folder shortcuts.
** The left area should allow you to store individual files, when people find a document, they would like to just open them immediately.
** The left area should allow you to store saved searches for later use.
** The CMIS backends should have a unique icon to make them stand out more.
** Users confuse a single and double-click and are often double-clicking on the Alfresco shortcut which brings up the editing screen. Treat single and double-click the same and add an [ Edit ] button to make changes to the underlying backend.
** It would be nice to have the artwork here match the monochrome theme, to give it a consistent look and feel.
Setting to NEW as ux-advise.
You are talking about LO specific dialogs (options > general > Use LO dialogs). Just out of curiosity: Do your users have similar problems with the default file dialog? This dialog provide options to browse folders, search for files, and to access network drives with a clean UI. From a UX perspective it's seldom a good idea to override system standards.
@Heiko: Yes this is for libreoffice's custom file dialog. It has a CMIS feature that allows you to connect to document management systems like Sharepoint, Google Drive, etc. which presently isnt integrated into the native system file dialog. As the CMIS is connecting to an external server, having the ability to search the server for a particular file is one of the main features of the mockup.
As Jay noted, the native file pickers do not have the advanced features found in the LO picker. We also have found it's nice to have a consistent picker on all platforms be it Linux, Mac and Windows and therefore use the LO picker.
This request is to enhance the LO Picker to be the best possible choice for those with similar requirements and needs.
Would be good to get adolfo's input on the file picker suggestions as he has recently done work on it.
Created attachment 113782 [details]
Mockup integrating search and Edit button
So this is, indeed, a broad bug report, which is already unmanageable ;-)
I basically agree with your suggestions, especially the single-versus-double-click thing, which should disappear in favor of single click and the “Edit” button; and the search box, a basic functionality. I’ve integrated those in the attached mockup.
Also, it has occurred to me that dropping the “Servers…” button in favor of a new equivalent command in the places and favorites list could be a good idea in order to save space in the top row of the dialog.
Nice work adolfo. Just wondered why the need for 'Favorite this Search' when users use the '+' to add folders to the favorites, so they could use the same '+' for adding a search to the favorites.
(In reply to Adolfo Jayme from comment #6)
> I basically agree with your suggestions, especially the
> single-versus-double-click thing, which should disappear in favor of single
> click and the “Edit” button; and the search box, a basic functionality. I’ve
> integrated those in the attached mockup.
So is the search functional on the local file system and CMIS?
> Also, it has occurred to me that dropping the “Servers…” button in favor of
> a new equivalent command in the places and favorites list could be a good
> idea in order to save space in the top row of the dialog.
I think changing 'Servers' to an icon like the two beside it would easily save space. The icon could be the same icon used in the favorites list when you add a CMIS to it or maybe a cloud icon. Noticed that the up folder button didnt have a tooltip. :D
We're replacing our use of the 'ux-advise' component with a keyword:
Component -> LibreOffice
Add Keyword: needsUXEval
While your suggestions make a lot of sense, the internal file dialogs will always have a bad usability compared to the native. It was introduced to support Qt4 (VCL backend kde4) and to provide additional CMIS functions. Both have been solved meanwhile or will be replaced soon, so the only reason for internal dialogs is the generic VCL backend and the headless mode. Therefore first steps have been made (bug 114484) to retire the internal dialogs. Rather than enhancing the functionality we should strip down any non-essential feature.
(Would be good to hear your opinion, Dave, with a lot of users.)
** Please read this message in its entirety before responding **
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!