Bug 87643 - SIDEBAR: New Shapes Tab and content panels
Summary: SIDEBAR: New Shapes Tab and content panels
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.5.0.0.alpha0+ Master
Hardware: Other All
: medium enhancement
Assignee: Susobhan Ghosh
QA Contact:
URL:
Whiteboard: target:5.3.0
Keywords: needsUXEval
Depends on: 100886 102197
Blocks: Gallery Sidebar-New-Decks
  Show dependency treegraph
 
Reported: 2014-12-23 18:39 UTC by Yousuf Philips (jay)
Modified: 2017-03-27 08:59 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
shapes sidebar pane in wps presentation (105.23 KB, image/png)
2014-12-23 18:39 UTC, Yousuf Philips (jay)
Details
MS word insert shape (46.67 KB, image/png)
2015-02-01 10:15 UTC, Viko Adi Rahmawan
Details
calligra flow's stensil box (118.71 KB, image/png)
2015-02-02 17:52 UTC, Yousuf Philips (jay)
Details
inkscape symbols tab (181.09 KB, image/png)
2015-02-27 01:09 UTC, Yousuf Philips (jay)
Details
insert shapes properties tab section (15.76 KB, image/png)
2015-03-26 06:21 UTC, Yousuf Philips (jay)
Details
Mockup for basic shapes in the sidebar (29.18 KB, image/png)
2016-06-27 19:55 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2014-12-23 18:39:26 UTC
Created attachment 111225 [details]
shapes sidebar pane in wps presentation

It would be useful to integrate the entire collection of drawing functions from the drawing toolbar into a sidebar pane. This would be most useful in impress, as it would free up the space taken at the bottom of the UI by the toolbar.
Comment 1 Cor Nouws 2014-12-23 20:35:53 UTC
Hi Jay, 
The tool bar will stay? It has the possibility to draw toolbars out of it, so have a separate floating toolbar for e.g. lines, shapes, ..

Cheers,
Cor
Comment 2 V Stuart Foote 2014-12-23 21:34:48 UTC
(In reply to Jay Philips from comment #0)
> It would be useful to integrate the entire collection of drawing functions
> from the drawing toolbar into a sidebar pane...

@Jay, hate to harp on the semantics of it, but you are asking for a new Sidebar Tab and associated Content panel(s) holding buttons from the drawing toolbar (and associated .uno actions) to place in the Sidebar Deck...

Otherwise though, this is a logical addition to the Sidebar

(In reply to Cor Nouws from comment #1)
> The tool bar will stay? It has the possibility to draw toolbars out of it,
> so have a separate floating toolbar for e.g. lines, shapes, ..

Yes, toolbar would have to remain, but probably not in view by default. That is until work on bug 85905, and similar, to allow multiple sidebar "content panels" to be undocked and active.  Currently with content panels for only a single tab active in the sidebar deck we have to retain toolbars. If multiple sidebar content panels could be undocked and active--we reduce the need for toolbars.
Comment 3 Yousuf Philips (jay) 2014-12-23 22:44:45 UTC
@Cor, yes the drawing toolbar would be hidden by default if the shapes tab was available in the toolbar.

@Stuart, yep thats the idea, shapes tab with shape type/group content panels. :D

Reading through the various comments that came in through the recent survey done by me and Heiko for impress, many users want a less cluttered UI. One user had expressed the reduction in the number of toolbars and i felt that if we could eliminate the second top toolbar row and drawing toolbar, there would be alot more room for the slide and sidebars and less clutter. From my testing so far, i believe we could easily eliminate the second top toolbar, as all its features are in the sidebar and in the context menu, but the only way to eliminate the drawing toolbar is to get its features into the sidebar.
Comment 4 Viko Adi Rahmawan 2015-02-01 10:13:32 UTC
Hello,
IMHO a sidebar is too overkill
Just an idea inspired by basic shape dropdown in standard toolbar, 
how if instead of just basic shape it changed to show all available shape preferably grouped and have recently used.
this is how MSWord insert toolbar is.
this way drawing toolbar can be hidden and user doesnt need to change sidebar pane back and fort between properties and shape if they want to draw and change properties
Comment 5 Viko Adi Rahmawan 2015-02-01 10:15:41 UTC
Created attachment 113016 [details]
MS word insert shape
Comment 6 Yousuf Philips (jay) 2015-02-01 18:30:21 UTC
(In reply to Viko Adi Rahmawan from comment #4)
> Just an idea inspired by basic shape dropdown in standard toolbar, 
> how if instead of just basic shape it changed to show all available shape
> preferably grouped and have recently used.
> this is how MSWord insert toolbar is.

The creation of a split/drop down button for shapes has been suggested in bug 84350.

> this way drawing toolbar can be hidden and user doesnt need to change
> sidebar pane back and fort between properties and shape if they want to draw
> and change properties

This argument was discussed in bug 84350 as well and having a constantly visible toolbar or sidebar when you need to add multiple different shapes has an advantage over a split/drop-down button.

The design team discussed last week about this sidebar panel and Kendy suggested that the sidebar tab also have the ability to set the shape's area and border colors from the sidebar, which is possible to set in the line and filling toolbar before a shape is drawn. So it would be useful to copy the 'fill' entry from the area properties section and the 'width' and 'color' entries from the line properties section, and these entries would only effect newly drawn shapes.
Comment 7 Cor Nouws 2015-02-01 23:41:02 UTC
(In reply to V Stuart Foote from comment #2)

> Yes, toolbar would have to remain, but probably not in view by default. That
> is until work on bug 85905, and similar, to allow multiple sidebar "content
> panels" to be undocked and active.  Currently with content panels for only a
> single tab active in the sidebar deck we have to retain toolbars. If
> multiple sidebar content panels could be undocked and active--we reduce the
> need for toolbars.

Maybe. Let's again look at then when the side bar issues are implemented and used for some time.
An advantage of the toolbar and panels is that you can drag the two/three that you need and float them where needed. really makes working faster an reduces mouse movement.
Comment 8 Yousuf Philips (jay) 2015-02-02 17:52:55 UTC
Created attachment 113059 [details]
calligra flow's stensil box

I've attached a screenshot of how Calligra's flowchart app has its shapes and in its other sidebar, you can see the settings for the shape fill and border.

Another flowchart app, Dia, also has a sidebar section for shapes, and also has a shape fill and border section below it which has a foreground and background color section which resembles gimp.
http://dia-installer.de/screenshots/highslide/images/large/diagerman.jpg

You can also see in this video tutorial of Draw, that the author takes out the shape drop down menus, so that he doesnt have to reopen the drop down menus each time he needs to grab another shape, which is a similar benefit of having it in its own sidebar tab.

https://www.youtube.com/watch?v=BdJOq63FiAA&list=PL47827064C2B32CCA&index=3
Comment 9 Cor Nouws 2015-02-02 20:41:31 UTC
Hi Jay,

thanks for the examples.

I guess I've already indicated that IMO an advantage of the floating toolbars is the flexibility in positioning of the relatively tiny elements.

Apart from that: when implementing them in the side bar, pls don't forget the functionality with Ctrl and double click.

Then when we are that far it's fine for me how happy we are with possibly removing current tool bar.
Ciao,
Comment 10 Yousuf Philips (jay) 2015-02-27 01:09:28 UTC
Created attachment 113725 [details]
inkscape symbols tab
Comment 11 Yousuf Philips (jay) 2015-03-26 06:21:54 UTC
Created attachment 114363 [details]
insert shapes properties tab section

Seems that there used to be a 'insert shapes' section in LibO 4.2 which was likely removed.
Comment 12 Cor Nouws 2015-03-26 09:36:05 UTC
It is impossible to drag the toolbar Drawing to a new position in master?
Version: 4.5.0.0.alpha0+
Build ID: c3087d969671e62182eb049850479e77190ccff4
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-03-22_02:33:12
Locale: nl_NL
Comment 13 Yousuf Philips (jay) 2015-03-26 11:32:51 UTC
(In reply to Cor Nouws from comment #12)
> It is impossible to drag the toolbar Drawing to a new position in master?

I had set it to be locked in bug 90244, so you'll have to right-click > Lock Toolbar Position to be able to drag it.
Comment 14 Yousuf Philips (jay) 2015-03-27 18:38:28 UTC
We had a design session today and the result can be found at

https://docs.google.com/document/d/1Sv3Q-XdnHElYGXX2m8OLbRAy1zyodcU231Gn2SkVRV0/edit?usp=sharing
Comment 15 Yousuf Philips (jay) 2015-03-27 20:26:46 UTC
Kendy pointed out that the 'insert shapes' section was removed from the properties tab because it doesnt below to properties (bug 73070), but it can be used as a basis for a shapes tab.

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7cd90162f1c4a1d763e40c8f9972fd59e219ccd1
Comment 16 Heiko Tietze 2016-05-04 11:26:40 UTC
Update of component -> Draw and keyword -> needsUXEval.
Comment 17 Susobhan Ghosh 2016-06-23 10:09:55 UTC
I've started to work on this, and would like a few more details.

1. The sidebar layout - talked to bubli and she suggested that accordion would take up too much time to code (rest of the summer). So any decision on which layout to be finally used would be appreciated.

2. Does this involve adding new native shapes to Draw? (not talking about user defined ones)

3. As for user adding shapes, does it involve drag & drop or just the Add button on the top right?

More question to follow as I progress.
Comment 18 Yousuf Philips (jay) 2016-06-23 12:58:19 UTC
(In reply to Susobhan Ghosh from comment #17)
> 1. The sidebar layout - talked to bubli and she suggested that accordion
> would take up too much time to code (rest of the summer). So any decision on
> which layout to be finally used would be appreciated.

The file & folder layout similar to the gallery.

> 2. Does this involve adding new native shapes to Draw? (not talking about
> user defined ones)

No new natives shapes.

> 3. As for user adding shapes, does it involve drag & drop or just the Add
> button on the top right?

Drag and drop would be good, its works for the gallery, and would allow users to create something in LO and easily export it to the shapes deck.

> More question to follow as I progress.

Look forward to them at the design meetings.
Comment 19 Heiko Tietze 2016-06-23 13:45:36 UTC
(In reply to Yousuf (Jay) Philips from comment #18)
> (In reply to Susobhan Ghosh from comment #17)
> > 1. The sidebar layout - talked to bubli and she suggested that accordion
> > would take up too much time to code (rest of the summer). So any decision on
> > which layout to be finally used would be appreciated.
> 
> The file & folder layout similar to the gallery.

The folder/file interaction hides options behind a selection, and that's not what we defined in the HIG. So how about an "ascordion" with fix sections? Im mean a panel with caption without the additonal features to expand/collapse. Isn't this easy to achieve?

(In reply to Susobhan Ghosh from comment #17)
> 2. Does this involve adding new native shapes to Draw? (not talking about
> user defined ones)
> 
> 3. As for user adding shapes, does it involve drag & drop or just the Add
> button on the top right?

You can easily drag'n drop drawings to the gallery (start on long press on the shape(s)/group). No need to do the same for basic shapes. We could also ignore the user-defined shapes.
Comment 20 Susobhan Ghosh 2016-06-27 14:37:53 UTC
How is the search functionality supposed to work out in the file/folder layout? The categories are hidden accordingly as per the results and the results are spread across categories? Or the categories remain static, and the results show up in the shapes pane below (all results)?
Comment 21 Yousuf Philips (jay) 2016-06-27 16:19:31 UTC
(In reply to Heiko Tietze from comment #19)
> The folder/file interaction hides options behind a selection, and that's not
> what we defined in the HIG. So how about an "ascordion" with fix sections?
> Im mean a panel with caption without the additonal features to
> expand/collapse. Isn't this easy to achieve?

Not sure how that was defined in the HIG, but would disagree with it as we have various things that are hidden behind an initial selection everywhere in the UI. The "ascordion" wouldnt be a good option as it would be a huge list of open sections that a user would have to scroll through.

(In reply to Susobhan Ghosh from comment #20)
> How is the search functionality supposed to work out in the file/folder
> layout? The categories are hidden accordingly as per the results and the
> results are spread across categories? Or the categories remain static, and
> the results show up in the shapes pane below (all results)?

I would assume a search results category would appear in the folder list and the resulting files would be listed in there.
Comment 22 Heiko Tietze 2016-06-27 18:43:57 UTC
(In reply to Yousuf (Jay) Philips from comment #21)
> The "accordion" wouldnt be a good option as it would be a huge
> list of open sections that a user would have to scroll through.

Check out the examples you put into the whitepaper. Most competitors do so and keep sections open.
Comment 23 Heiko Tietze 2016-06-27 19:55:30 UTC
Created attachment 125949 [details]
Mockup for basic shapes in the sidebar

Susobhan's idea is to add a tab to the sidebar which holds the basic shapes only. The advantage is to get rid of the drawing toolbar in Draw, and the lengthy menu in Writer > Insert > Shape would have a redundant interaction.

According the design session from comment 14 we have two options: 1) the shape categories (Lines & Arrows, Curve, Connector, Basic Shapes, Symbol Shapes...) are shown as content panels with the actual shapes as content; 2) the category is being selected first from a list and the shapes are shown in respect to this selection. My preference is #1 because of the clean layout and the one-click interaction. Advantage of #2 is the conformity with the current gallery (that should be reworked according #1, though).

The search is not easy to implement. While collapsing panels and hiding items that do not match the search/filter criteria would be nice, this code is very difficult. Therefore the mockup just disable (dim) the non-fitting shapes. Anyway, the number of shapes is not that high and this filter would rather be the prototype for the gallery.
Comment 24 Yousuf Philips (jay) 2016-06-28 00:52:10 UTC
(In reply to Heiko Tietze from comment #22)
> Check out the examples you put into the whitepaper. Most competitors do so
> and keep sections open.

Yes calligra, visio 2007, yEd and lucidchart have accordians with contractible sections, but none have them always open, which is what you were proposing in comment 19. Inkscape, dia, and visio 2010 use the folder/file approach.

(In reply to Heiko Tietze from comment #23)
> Susobhan's idea is to add a tab to the sidebar which holds the basic shapes
> only. The advantage is to get rid of the drawing toolbar in Draw, and the
> lengthy menu in Writer > Insert > Shape would have a redundant interaction.

The main benefit that this sidebar deck is intended to have would be to contain non-basic shapes that arent in the drawing toolbar for use in Draw, so that Draw can be more useful. Having the basic shapes as a separate content panel in the deck would make useful for those who dont want to use the drawing toolbar in modules where shapes arent a primary part of the functionality (i.e. writer, excel). Even with basic shapes in the deck, that wouldnt eliminate the reason to have them in the Insert > Shape menu.

We maybe misunderstand each other when it comes to the design because we might be talking about different content panels of the deck. My approach to the design of the deck is the programmably viable style with a 'default' content panel of basic shapes which would be scrollable to fit all the shapes (similar to wps's shapes sidebar) and a folder/file design for the 'more' content panel, with or without a search capability.
Comment 25 Susobhan Ghosh 2016-06-28 04:55:00 UTC
(In reply to Yousuf (Jay) Philips from comment #24)

> The main benefit that this sidebar deck is intended to have would be to
> contain non-basic shapes that arent in the drawing toolbar for use in Draw,
> so that Draw can be more useful. Having the basic shapes as a separate
> content panel in the deck would make useful for those who dont want to use
> the drawing toolbar in modules where shapes arent a primary part of the
> functionality (i.e. writer, excel). Even with basic shapes in the deck, that
> wouldnt eliminate the reason to have them in the Insert > Shape menu.
> 
> We maybe misunderstand each other when it comes to the design because we
> might be talking about different content panels of the deck. My approach to
> the design of the deck is the programmably viable style with a 'default'
> content panel of basic shapes which would be scrollable to fit all the
> shapes (similar to wps's shapes sidebar) and a folder/file design for the
> 'more' content panel, with or without a search capability.

Yes, I guess we do misunderstand each other. This is what I understood from what you clarified: 2 panels - one with basic shapes (without search, just like WPS), and an 'more' panel with a file/folder layout (with/without Search). Am I correct?

If I am, can you clarify what is the purpose of the 'more' content panel?
Comment 26 Cor Nouws 2016-06-28 11:10:25 UTC
(In reply to Heiko Tietze from comment #23)

> Susobhan's idea is to add a tab to the sidebar which holds the basic shapes
> only. The advantage is to get rid of the drawing toolbar in Draw, and the

"basic shapes only" here means all the ones from the tool bar?
Comment 27 Heiko Tietze 2016-06-28 13:26:08 UTC
(In reply to Cor Nouws from comment #26)
> "basic shapes only" here means all the ones from the tool bar?

Yes, the sidebar would be an alternative to the drawing toolbar (talking Draw).
Comment 28 Yousuf Philips (jay) 2016-07-01 06:49:30 UTC
(In reply to Susobhan Ghosh from comment #25)
> Yes, I guess we do misunderstand each other. This is what I understood from
> what you clarified: 2 panels - one with basic shapes (without search, just
> like WPS), and an 'more' panel with a file/folder layout (with/without
> Search). Am I correct?

Yes correct.

> If I am, can you clarify what is the purpose of the 'more' content panel?

It is to provide non-builtin shapes that are common in diagram apps. These shapes will be stored in files, similar to how we have it for the gallery.
Comment 29 Commit Notification 2016-07-08 20:11:29 UTC
Susobhan Ghosh committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ab9708e179762f97bd1a0ee4c0d4b439f1dabfd5

tdf#87643: Default Shapes Panel for Shapes Deck

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 30 Commit Notification 2016-08-20 14:14:06 UTC
Susobhan Ghosh committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=44216ddbc620a1c05e98dda1f63ed6df0eae5275

tdf#87643: Make Shapes Deck experimental

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.