[geeklog-devel] Config GUI issues
Mark R. Evans
mevans at ecsnet.com
Fri Jan 4 10:54:08 EST 2008
> 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
>
>
More information about the geeklog-devel
mailing list