Improvements to "View Menu"

[Alexander Obuhovich]

In-Portal has a "View Menu" almost on each of templates, that are used to display tabular data, e.g. grids/lists.

There was a lot of menu items in earlier versions of In-Portal, but right now there 3 menu items:

• Select Columns - opens dialog window for rearranging grid columns (show/hide/move left/move right)
• Auto-Refresh - will open submenu, where user can make grid auto-refresh periodically
• Per Page - will open submenu to change row count that are simultaniosly displayed in the list

Also when user changes filters, sorting or per-page, then they are stored into PersistantSessionData table to make sure that user will see current grid the same way he left it, when he logged-out from Admin Console.

Depending on project specifics, where In-Portal is used there could be a grids with 100+ columns and 100+ rows that needed to be viewed at all times.

With such amounts of data user will need to change sorting/filters on a regular basis to inspect data from different view angles. In current implementation of grids there is no way so remember and then recall previously used filter set to speed up things.

I propose to add such feature as "view presets" (or any name that fits my further description of this feature). I'll explain below how it works.

• user can have unlimited number of "view presets";
• when user changes filter/sorting/per-page, then he can save that combination using meaningful name;
• at any time user can switch grid to be displayed according to "view preset", that user have saved before;
• all "view presets", that were created will be available in left menu under that section (hitting "+" will do an ajax query to retrieve them from database);
• clicking on a section will open default "view preset"; clicking on a "view preset" will open/switch to clicked "view preset".

New "Save As" submenu will be added to "View Menu" (after separator maybe), that will allow to save/create "view presets":

• View Preset Name #1
• View Preset Name #2
• ....
• View Preset Name #N
• Create New ...

Item "Create New ..." will prompt user to enter view present name to be created. After creating new "view present" corresponding menu tree node will be refreshed to show it.

When user changes filters/sorting/per-page, then current view preset will be automatically switched to "Default", since it no longer will correspond any of presaved "view presets".

Main concept here is to create useful functionality with less interface change as possible.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Dmitry A.]

Hi Alex,

I like and support the idea and approach, but would make the interfaces look the following:

View Menu

=========

Menu Presets

  - Save As...

  - Menu Preset #1

  - Menu Preset #2

  - Delete

Select Columns

Auto-Refresh ->

Per Page ->

Let me know what you think guys.

DA

[Alexander Obuhovich]

What "Menu Presets" is? If you are planning to use exactly this name in "View Menu", then I disagree. In case if it is just a placeholder that will be replaced with the phrase we all agree on, then I'm ok with it.

I see you've added "Delete" option. I forgot about it. Maybe "Delete Current" will be more appropriate, since from menu user can't guess what exactly was deleted, since I thought it deletes "view preset" just above it.

[Dmitry A.]

"Delete Current" is okay.

"Menu Preset" is just the placeholder for the sub-menu. We can call it whatever we decide on. Options:

1. View Presets

2. Menu Presets

3. Column Presets

4. Grid Presets

I like "View Presets" or "Grid Presets" so far.

DA

[Alexander Obuhovich]

Here is my logic about the naming:

Since it's in "View Menu" then it affects what is being displayed and "View" word inside "View Menu" is redundancy. "Menu" word isn't good enough, since it has nothing to do with menu.

Term "grid" is not understandable even by google translate, so I guess it also is declined.

All that stays is "Presets". This one alone doesn't work too, since that menu is ONLY FOR SAVING and not for selecting a current preset. That's why I named it as "Save As" initially.

[Dmitry A.]

1. I would rename View to View Menu so it's more intuitive, often we need View button in the toolbar for different actions related to viewing/showing the record details

2. The whole Menu I would do this way:

View Menu

=========

Presets (indicates it has Presets for View Menu)

  - Save (if it's new we'll be offered a name, if it's existing we overwrite it)

  - My preset  (custom name)

  - Your preset (custom name)

  - Delete current (deletes currently loaded preset if any, if nothing - does nothing)

Select Columns

Auto-Refresh

Per Page

What you think?

DA

[Alexander Obuhovich]

What clicking on "  - My preset  (custom name)" will do? I ask, since you wrote that "Save" will somehow decide that preset should be overwritten.

This won't work, since I wrote in my original post, then after a change is made, then current preset is reset to default. Without it you will be unintentionally changing current preset to create new one.

As per my original post "Save" will save as new always and clicking a preset name will overwrite selected preset.

Maybe this will be better:

View Menu

=========

Presets (indicates it has Presets for View Menu)

  - Create new (if it's new we'll be offered a name, if it's existing we overwrite it)

  - Save As "My preset"  (custom name)

  - Save As "Your preset" (custom name)

  - Delete current (deletes currently loaded preset if any, if nothing - does nothing)

Select Columns

Auto-Refresh

Per Page

[Phil -- wbtc.fr --]

about create/save/delete I propose this interface, directly in the drop-down menu

(text field) + button "save"
"saved preset 1" + "x" button to delete

 

exemple menu :

_________  -  save

My preset 1 - x

My preset 2 - x

My preset 3 - x

looks as intuitive as google interface, isn't it? ;-)

2011/3/2 Alexander Obuhovich <aik....@gmail.com>

[Dmitry A.]

I am afraid Phil we are NOT up to speed with JS Interfaces yet :(

This means we can't do it as you described (I wish we could).

Back to Alex's questions:

Here is a new version. I think we can stick to the most know terms (Save As... Save Delete) separating them from the actual Presets a bit (we have some spacing there now).

View Menu

=========

Presets (indicates it has Presets for View Menu)

  - Save As... (if it's new we'll be offered a name, if it's existing we overwrite it)

  - Save

  - * Load "My preset"  (custom name)

  - Load "Your preset" (custom name)

  - Delete (deletes currently loaded preset if any, if nothing - does nothing)

Select Columns

Auto-Refresh

Per Page

Please let me know if all clear and if any questions.

DA

[Alexander Obuhovich]

About Phil's post, then maybe we can put some input box just inside menu (if our menu script allows that).

About "if it's existing we overwrite it" I'll explain you in private, since I've made 2 post already about this and you still don't get that we don't know what current preset is and that every change (while preset is selected) will actually change default preset instead and then you can choose to overwrite preset of you choise with default one.

[Phil -- wbtc.fr --]

Dmitry, I understand my proposal isn't the easier, but at least if we use small links to delete saved preset, it'd be really easier and intuitive, this way we would need just a pop-up for creating a new preset, all others actions could be done directly in menu.

About renaming, is it so important? I can create a new one, and delete the old, would be the same at the end, without an ennoying system to manage names ;-)

2011/3/3 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Nobody was talking about renaming.

[Phil -- wbtc.fr --]

sorry I meant "overwrite" :)

2011/3/3 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

Overwriting is important, since if you change your view preset frequently you won't creating a temporaty preset every time you need to save changes and then delete old one.

[Phil -- wbtc.fr --]

in this case, yes it's important, I agree.

May we can do like gmail automatic answers, a menu like this:

view preset

  -- preset A

  -- preset B

save preset (save current view when clicking on the name)  -- preset A

  -- preset B

  -- create a new preset

delete preset (delete clicked preset)

  -- preset A

  -- preset B

or mix with my first proposal and do:

view preset

  -- preset A - x

  -- preset B - x

save preset (save current view when clicking on the name)

  -- preset A

  -- preset B

  -- create a new preset

or compact version (my preference)

preset view

  -- preset A - [update] - [x]

  -- preset B - [update] - [x]

  -- create new preset...

2011/3/3 Alexander Obuhovich <aik....@gmail.com>

[Dmitry Andrejev]

Hi Phil,

Not to spoil your ideas, but I see a lot of redundancy here... Why we need so many sub-menus?

Is there any operation you can't do with this Menu layout?

==========

Presets (indicates it has Presets for View Menu)

  - Save As... (if it's new we'll be offered a name, if it's existing we overwrite it)

  - Save

  - * Load "My preset"  (custom name)

  - Load "Your preset" (custom name)

  - Delete (deletes currently loaded preset if any, if nothing - does nothing)

==========

Thanks.

DA

--

Best regards,

Dmitry A.

[Dmitry Andrejev]

I like the last option

preset view

  -- preset A - [update] - [x]

  -- preset B - [update] - [x]

  -- create new preset...

But I am not sure we can actually do this as nice as Google with the current Menu.

-- 

Best regards,

Dmitry A.

[Alexander Obuhovich]

Selecting what preset to use should not be done from view menu to remove redundancy, since it already can be done from left menu tree (as I've mentioned in my original post).

[Dmitry A.]

Hi guys,

We have checked and looks like we are able to use HTML in Menu Elements so "My Preset [save] X" can possible work out.

DA

[Phil -- wbtc.fr --]

Alex, is this so problematic to be able to click on a view on left and also in view menu? Why not giving this ability? It wouldn't be intuitive to be able to save, delete, but not view the preset we are about to delete...

I'm happy to read that you confirm we can use HTML, this would save us many popups. May we could just ask confirmation for deletion in a JS alert popup?

2011/3/4 Dmitry A. <dand...@gmail.com>

[Alexander Obuhovich]

I've talked with Dmitry and we agreed, then clicking on preset itself to select it is quite useful from interface viewpoint too. So we all agree with you on this one.

I'll try to finalize here:

In there database there will be 2+ presets:

• default (without name as for now)
• sandbox (used for temporary data storage)
• user preset 1
• user preset 2
• ....
• user preset N

Sandbox preset won't be visible in menus, but it will be used to temporarily store columns/filters/per-page until user decides to save them under preset of his choice OR create new preset. Sandbox preset will be used ONLY, when user has selected "user preset X". This will ensure, that "user preset X" isn't unintentionally changed by system until user decides to do that manually. When user is using "user preset X" and decides to create a new preset or update existing one, then all data from sandbox preset will be copied to the destination preset.

Switching to "user preset X" will overwrite sandbox preset contents with contents from selected preset. Then sandbox preset will be used to store any change user will made and to protect "user preset X" for unintended changes.

When default preset is selected, then changes will be saved directly to it without use of sandbox preset. This will ensure backwards compatibility and grid will work as before when presets are not used at all. When user is using default preset and decides to create a new preset or update existing one, then all data from default preset will be copied to destination preset.

Technically current preset name will be stored in session, but actual preset data read/write operations will happen on sandbox preset, when "user preset X" is being used.

Visually I agree with Dmitry's version of Phil's proposal:

Presets

  -- user preset A - [update] - [x]

  -- user preset B - [update] - [x]

  -- create new preset...

Where "Presets" is top submenu under current "View Menu". Maybe update and delete links will be more intuitive if replaced with nice small icons, maybe like our save/cancel toolbar buttons, but smaller.

Yes, we can ask user confirmation before actually deleting preset from database. Maybe preset deletion won't be causing page refresh so I can quickly delete more then one of them.

Option of displaying presets in left menu is temporarily discarded due inability to fully control it.

[Phil -- wbtc.fr --]

will the preset also keep record of each column width? You surely understand the use, we don't need the same width when displaying 3 columns or 30.

About menu behavior, may we could replace [update] color or word itself ( [ok)] ) when save is succesfull.

2011/3/4 Alexander Obuhovich <aik....@gmail.com>

[Alexander Obuhovich]

will the preset also keep record of each column width? You surely understand the use, we don't need the same width when displaying 3 columns or 30.

Of course column width will be recorded in the preset.

About menu behavior, may we could replace [update] color or word itself ( [ok)] ) when save is successful.

This depends on whatever we will be using ajax or not. When ajax is used, then maybe even opened menu stays open after clicking update, but I suppose we won't be using ajax and will just refresh page for user to see the difference (like now, when user changes a filter settings).

[Dmitry A.]

Hi Alex,

I have reviewed this discussion and I think we are ready to summarize this into a Task.

What you think? if so would you please take care of this?

DA

[Alexander Obuhovich]

Task: http://tracker.in-portal.org/view.php?id=1012

[Alexander Obuhovich]

I've found, that similar functionality is available in Jira Issue Tracker (https://confluence.atlassian.com/pages/viewpage.action?pageId=185729481).

There you filter/sort data in the grid and then can save that as a "favorite filter". If later you select a favorite filter, change it then you have 2 options:

• update current filter ("Save")
• create new filter with given settings ("Save as")

This way if you suddenly need to filter by absolutely different criteria you can always save current filter for later use.