I think we need some button size consistency, and would look better if they were the same height as the ‘configure’ button, but half the width - like the ‘Forw./Backw.’ buttons, so they can sit side by side.
Don’t worry about the icons - they could be changed if necessary.
We just need to decide where to put the common dashboard edit link/button… unless we just remove it completely, and instead access it as @pb66 has said via setup => dashboards.
This would be a good addition, and @mattjgalloway has added some css recently which does exactly that.
If you edit L521 of dashboard/Views/js/designer.js from; widget_html += "<ul class='dropdown-menu' style='top:30px' name='d'>"+select[z]+"</ul>"; to; widget_html += "<ul class='dropdown-menu scrollable-menu' style='top:30px' name='d'>"+select[z]+"</ul>";
you will get as per the screenshot below.
Auto-growing is a nice feature, and as you have said avoids seeing a lot of blank space.
The palette border looks much better, the scroll-able dropdowns are good and moving the 2 buttons from the 2nd navbar is a huge step towards getting rid of that bar altogether.
I wonder if rather than having 2 config buttons, the same button could be used for both dashboard config and widget config depending on whether a widget is selected at the time of clicking.
It’s also a shame we still have the full width toolbar for the one remaining button in view-mode. Would it be feasible to make a tiny palette with a transparent background in view-mode with one single button, also with a transparent background so only the icon was visible? this “floating icon” in view mode could replace the “edit icon” and that whole 2nd navbar in view mode.
Since I notice the new toolbox palette always initially appears in the same location, the “transparent edit button” could appear to open into the full palette and close again as you toggle view and edit mode without any mouse movement if the 2 palettes positions were the same, obviously the position would reset each time it’s clicked if the edit palette is dragged, but it does that anyway, I think that is a better option as the transparent edit-mode’s button position should be consistent to be easily located.
Naming and icon have to be agreed for sure. Added opacity style to reduce visibility
The question is how big should it be. On normal PCs it’s fine but its not usable at all for mobile application. It will be hard to move around if is just the small standard icon, so I added a text. Using my phone it’s too big for sure and occupying too much screen when using a button with text.
Suggestions? Maybe just a simple gear icon as used by many other applications for setup menus?
If you can’t find anything suitable in bootstrap, I’ve attached 2 images below to consider.
Both are PNG’s, web optimised with transparent backgrounds, one in shade #333 (to match the black used in emoncms) and another in #0699fa - the same blue as used in the forum.
@Andreas_Messerli - Do you want to replace the text with an icon first - before merging the PR?
Good work! I look forward to pulling in the changes to see it “in the flesh”. I agree the gear icon would be better too,
From the screenshots alone though, I think a gear icon on a transparent button/palette would give a more prominent icon than reducing the opacity of the whole palette including the icon. At the same time it would also be more discreet on the whole whilst retaining a larger grab area so if you did want to move the toolbox you could do so by grabbing “around” the icon, although I’m not sure there is a need to reposition a collapsed toolbox/palette.
@Paul - I think we should pull in the current changes without the new icon as the general concept probably needs assessing before deciding the finer points, there will no doubt be further changes and a change of icon can happen at any point.
Paul, before merging anything, I check through the code, load up a diff, check for errors & functionality using different browsers & platforms which I’ll be doing this evening, by which time Andreas may have added the icon, which would be my preference.
I now used a transparent background DIV with a slightly red tone to make it at least a little bit visible. The button itself is now normal visible and does not have opacity. When the outer div is completely transparent the user is not able to see a dragging area. I used 0.1 as color transparency value.
The positioning is a different topic. With it beieng on the right we of course maximize the usage of the dashboard on the left side and “normal” user behavior is reading from left to right with a slight down path. So the icon could be overseen. But putting it on the left is maybe annoying because in most cases its over some content.
Instead of using a button with an icon in it, would it look better if it was just the icon?
The icon could then be a little larger and there would be no need for a text label (keeping it small and avoiding translation issues).
Looks better being opaque, it doesn’t need to divert attention away from the graphs & widgets
Maybe ‘not opaque’ when mouseover to highlight it’s purpose??
I don’t see the point in it being moveable, as whenever you change or reopen a dashboard it defaults to the top right. Why would you want to move it?
As you’ve already commented, possibly need further CSS adding to present it differently on small screens.
I have just submitted a PR for a transparent button/palette background in view mode and at the same time aligned the 2 palettes a little better to each other and tighter into the corner.
The icons do still need to be much bigger IMO, as I’ve already mentioned, I would consider dropping the text labels altogether, but at the very least the “config” and “preview/edit” buttons should be half-width and double height like the “undo/redo” or “forward/backward” button pairs.That would make the single “edit” icon easier to see/select when in view mode.
I don’t know off-hand how to alter the existing icon sizes, but if we are thinking of introducing some custom icons maybe we should add them in different sizes eg “emon-iconA-small” and “emon-iconA-large” to get a better quality rather than enlarging small icons, there seem to be a few guides out there for creating your own glyphicon files,
A few suggestions (including some we already use), ignore the blue color I’ve used, I think the icons just need to be monochrome to be converted to glyphicons.
and Move backwards/down and move forwards/up
and undo and redo
OR Containers and frames
text boxes, Visualisations, Dials and Widgets
Configure (both dashboard and widgets?)
Edit mode, View mode, Delete Item(s), Save dashboard
@jon had already applied a correction based on @Bill.Thomson 's first incorrect correction. So I wasn’t sure whether to undo or redo Jon’s correction, therefore I just put it right instead, sorry for leaving these comments hanging