[geeklog-devel] Config GUI issues

[Mark R. Evans]

> I would prefer we not create any more tabs as the core->menu was already 
> longer then I wanted. We need to ensure the menu does not wrap on 
> narrower browsers. Using the dropline menu has regained space but if we 
> do any more significant restructuring it would be something considering. 
> This option effects more then just the editor so it may be better placed 
> on the Site Tab - thats easy to do.

Trying to ensure the menu doesn't wrap is the wrong area to focus. Don't 
try and make more space, make the menu wrap gracefully.  What looks good 
with English selected may be much wider when another language is selected. 
My point is that you'll never win the no-wrap game.  Assume it is going to 
wrap and do it gracefully.  The current menu does not wrap well, so that 
would be an area to focus.

Another approach to a two-tiered menu could be to use a select box to 
choose Core, pluign X, plugin Y, or plugin Z.  This removes the need for a 
two tiered approach. Not sure what it gains you, but it would keep that 
section of options from possibly wrapping in the future if you had 10 or 
15 plugins installed that used the configuration API.

> Agree this would be better and will look at extending the UI Javascript 
> methods to add a select type element for the 'Add Element' feature. This 
> may have to wait to see if we move the config manager to use AJAX as now 
> the DHTML has to be more generic. The 'Add Element' is a generic UI JS 
> function and this would require it be unique to add a select that has a 
> unique set of options. Easy to do with AJAX but not sure I want to break 
> the UI code now to add this feature.

The current state of the configuration system concerns me a little.  I 
understand the goal of using as generic a set of tools as possible to 
allow easy extention and use by plugins.  But, if this is at the sacrifice 
of having a configuration system with selectable options, limits and 
validations, I'm not sure that is the right choice.

I realize what is gained by moving to an online configuration system.  No 
more butchering of the config.php file (missed end quotes, semi-colons, 
etc.) and no more FTPing it up / down to edit.  But, as it stands right 
now, there are a few things that are lost.  Specifically all the inline 
documentation that tells you what each option does and the list of valid 
values.  To me, this is a big piece that must be duplicated in the online 
version.

Since JavaScript is now required to perform configuration, why not 
continue to exploit that requirement and implement some nice pop-up 
windows or tooltips for help or at least duplicate what was in the 
config.php.

I strongly believe if an option has a finite set of selections, that set 
must be presented to the user through the interface.  Allowing users to 
free form the entry will result is just as many support issues as 
mistyping in the old config.php.  While the current online configurator is 
no worse than hand editing the config.php, I believe it should aim higher 
than being no worse.

Don't get me wrong, I think what has been done so far is an excellent 
start and is very well done from a technical perspective. I believe it now 
needs to be addressed from a user perspective which may change or enhance 
how it currently works.  It is a great starting point, but is it ready for 
prime time?

A final comment on the current system...

A user support issues I've seen with tabbed menus is when a user makes a 
change, then clicks on another tab, in this case the change is lost. 
But, in contrast, the story editor, switching tabs doesn't loose the 
changes between the screens.

We all know it is because in the story editor, JS is being used to hide 
each of the non-active tabs and you are really dealing with one big page 
and the online configuration is actually calling a separate page with each 
tab.  My point is that we have an inconsistency in the various areas of 
Geeklog when it comes to tabbed menus.  A possible solution is to detect 
changes and use JS pop-up to warn that changes have been made, do you want 
to save before continuing.

Thanks!
Mark



On Thu, 3 Jan 2008, Blaine Lang wrote:

> Mark R. Evans wrote:
>> THEME -> MENU ELEMENTS
>> This should be a drop down of allowed values. If I put 'Home' in there, 
>> nothing happens, but if I enter 'home', it will place the Home link in the 
>> menu. Since this is a static list of valid values, make it a drop down. 
>> This will cut down on support issues.
>> 
>> TOPICS AND DAILY DIGEST -> TOPIC SORT METHOD
>> This should also be a drop down selection. There are only 2 valid options 
>> for this field. Again, makes it more user friendly and will cut down on 
>> support issues.
> Agree this would be better and will look at extending the UI Javascript 
> methods to add a select type element for the 'Add Element' feature. This may 
> have to wait to see if we move the config manager to use AJAX as now the 
> DHTML has to be more generic. The 'Add Element' is a generic UI JS function 
> and this would require it be unique to add a select that has a unique set of 
> options. Easy to do with AJAX but not sure I want to break the UI code now to 
> add this feature.
>> 
>> TOPICS AND DAILY DIGEST -> WHAT'S NEW
>> If possible, use something besides seconds for the time entry, use minutes 
>> or hours and convert on save. Seconds are very confusing, it is difficult 
>> to know just how long is 172800 seconds. But, something like 48 hours is 
>> pretty clear.
> I think the change would need to be made to the COM_whatsNewBlock as we have 
> no specialized handlers in the config class. We can certainly make the 
> setting be hours and change the COM function - Dirk?
>> 
>> 
>> USERS AND SUBMISSIONS
>> I don't think this is the right place to set the advanced editor options. I 
>> would create a new tab for editor specific items.
> I would prefer we not create any more tabs as the core->menu was already 
> longer then I wanted. We need to ensure the menu does not wrap on narrower 
> browsers. Using the dropline menu has regained space but if we do any more 
> significant restructuring it would be something considering. This option 
> effects more then just the editor so it may be better placed on the Site Tab 
> - thats easy to do.
>> 
>> Actually, I think the entire organization should probably be revisited and 
>> mapped a little differently. I understand this was the format of the 
>> config.php file, but if you are planning on improving the overall 
>> configuration, a better organization might be worth looking into.
> I've looked at the organization a few times while trying to see if I could 
> eliminate one of the tabbed sections to reduce the size of the Core->submenu 
> and it may be just that I've been using GL too long and it's the config 
> optons are too familiar now to me but I am not seeing any clear 
> restructuring. I think it's actually far easier to find a setting now then it 
> ever was in the config.php
>
>> 
>> CONFIGURATION -> THEMES
>> Why not make the Theme field a drop down, there is already a function, 
>> COM_getThemes() that returns a list of available themes. This would make it 
>> a bit more user friendly and keep someone from mis-typing a theme name.
> Possible but would require extending the class or adding a new config value 
> type. Worth considering if there are more config settings to use that 
> feature.
>
>
> Blaine
> _______________________________________________
> geeklog-devel mailing list
> geeklog-devel at lists.geeklog.net
> http://eight.pairlist.net/mailman/listinfo/geeklog-devel
>
>