Toolbox Style
I'm cleaning up some of AspNetEdit's widgets, the Toolbox and the PropertyGrid. My original plan was to use GTK#'s TreeView for both, but while working on the toolbox I realised that it may not be the best solution for this particular item.
Why? Well, it depends on how people want the toolbox to work. Should the basic mechanism stay as it is, a TreeView-style list with expandable categories in one huge scrollable box? Or should it be similar to Outlook, with effectively a radio-button choice of one category that gets its own scrollable area?
I've used Glade to create a side-by-side mockup of the two approaches:
I personally prefer the one on the left, but it does raise scalability problems with large numbers of categories, though this is not likely to be a common scenario. It would also make it more difficult to reorder categories.
Comments below, please.
Comments
Image on monologue is broken
Hi,
the url of the image in http://go-mono.com/monologue is broken.
I personally prefer the right column.
Greetings from Germany,
TheUndeadable
Fixed already
Fixed already, but Monologue hasn't picked it up yet :-)
Mixed feelings.
I like both of them.
The reality is that both are using categories, and when they grow, they will both be inadequate.
It presents a little bit the same problem that PropertyGrids have: which is that categories are fine some of the time, but people need to sort them by name to find things every once in a while.
Getting the Outlook-like browser to work correctly and with the right feeling might be a lot of extra work as well.
True
True. Maybe offering alphabetical sorting and some kind of search/filter box might help, though the lack of any text description limits what can be done with searching. The categorisation is actually performed by the user, or pre-loaded with the IDE, unlike in the PropertyGrid with its attributes
This does raise some interesting points which I will have to consider when looking at the PropertyGrid. I have an idea for that actually: sort by level in inheritance hierarchy,
Actually, I think it is possibly the easier of the two, as its internal structure is quite similar to what I've already written. I may even animate the expanding categories ;-)
I, too, like both of
I, too, like both of them.
And Miguel raised a really good point that affects both of them:
It presents a little bit the same problem that PropertyGrids have: which is that categories are fine some of the time, but people need to sort them by name to find things every once in a while.
But in my opinion it doesn't affect the right one as much as the left one, because you could make a checkbox (or a context menu entry) that enables/disables grouping, so that the user would be able to select between the full list and the grouped list.
Just answer
Just answer in these words: "Maybe just check the tree when a category is clicked if it's got any other categories visible - if it has - fold them, and unfold only the selected one. Should be fast and easy to get used to."
Microsoft use left style in
Microsoft use left style in Visual Studio 2003... and right style in Visual Studio 2005. Users request ?
I like it
Personally i like the left one too. I think the buttons should be a bit smaller like in VS.NET. But I really like the functionality that it offers.
oops
Dang I can't edit my post so i willjust add another one. sry if this clutters it up.
Anyway. I do like both of them, but i prefer the left one. I would be cool is if you could offer the user the choice of either of them. Like in the preferences offer the tree view or the box veiw thing. That to me would be cool.
Just a thought.
Preference?
I choose the tree menu because on my laptop 1024x768 is as good as it gets; thus space is critical. Most of the button-style interfaces don't work when their window is made very narrow but if I can see just a letter or two of the tree-style, I can still navigate okay.
Why is this an either/or question? (just asking - I don't really understand the implications since I'm not really a Mono programmer)
Why is this an either/or
Why is this an either/or question? (just asking - I don't really understand the implications since I'm not really a Mono programmer)
Well, as percent20 commented below, it would be possible to write both and give the user an option to switch between them. However, this isn't really an optimal use of effort, and the time that I can give to the project would be better spent working on other parts of the editor.
3rd Option
A 3rd option would be to have a ComboBox for the categories, with a ListBox underneath it. The interface would scale better with more categories, and you could display everything in alphabetical order under the "ALL" category.
An interesting idea,
An interesting idea, especialy the scalability aspect. However, it would have the same difficulties with sorting that the button version has, and would require more clicks to access the categories.
Why not merge them?
I like the visual presentation of the one of the left, but the scroll bar over everything for the one on the right. How bad would a scroll bar look to the right of the buttons? You could show all of the buttons entries below it, add more buttons without height worries, and still provide an all button. I think that would address most of the comments.
The tree is better
I prefer the tree view, simply because you can have more than one category open at a time. That seems to be better than clicking buttons, plus groupings are sometimes not intuitive. I would also suggest adding "All" category, and perhaps a serch-as-you-type feature.
Cheers!
- Filip
The example on the left has
The example on the left has the downside that the buttons "jump" about whenever the selection is changed. This was deemed so bad from a user experience POV that it was changed so all the buttons stayed at the bottom in later versions of Outlook. Indeed, this form of selection is essentially a tabbed page. Alan Cooper's About Face 1995 edition talked about the downsides of tabs jumping about and how that impacted the usability of a metaphor.
Thanks
Thanks, that's interesting to know. That could be why it was changed in VS2005. I would think that keeping all the buttons in a list at the bottom is an even worse UI decision, as they actually need to be shuffled then...
I still don't like the aspect of the treeview that you can lose categories off the bottom, but this is inevitable for sufficiently large numbers of them. Then the only category the left-hand version wins in, for me, is the aesthetics. Given sufficient polish I suspect the treeview could match it, but it will be more difficult.
I'm leaning towards having toggle buttons at the top to switch categories and a filter box on/off. It's important that the toolbox doesn't become too large or complicated.
I'd go with a combination
I'd go with a combination approach (of sorts). I can't stand tree control layouts so I definately prefer the one on the left. However, rather than going with the traditional button jump thing, let each click of a button expand and contract each section. That would allow the user to open/expand and close/contract each section independently. Alot of us... maybe not the laptop users, but my desktops run at very high resolutions so I generally have the room to have more than one section open at at time.
I like the right one. It
I like the right one. It feels more like other gnome apps. You can also have more space with this approach, since the buttons take more space than the treeview arrow.
I prefer the style on the
I prefer the style on the right. I think one could find items more quickly by simply scrolling over all of the options than by clicking each individual button and then scrolling through just those items in that category. (That still assumes that one has a quick way of expanding the entire tree.) I think there should be more delineation between the categories and the items within them, though. A slight indentation perhaps.
Since you compare this to
Since you compare this to Outlook, I'd like to suggest something that Outlook does that people might find interesting.
Outlook has a "my shortcuts" section where you can customize the entries it displays. I would find this very usefull as I could add here the controls I use the most and so avoiding having to scroll to find the controls under different sections.
I prefer left one.. treeview
I prefer left one.. treeview isn't so easy to use! :)
You could do something in
You could do something in the middle. The problem with tree is that you have to fold one category and unfold another, while you just select category once in the sidebar style.
Maybe just check the tree when a category is clicked if it's got any other categories visible - if it has - fold them, and unfold only the selected one. Should be fast and easy to get used to.
Outlook style side bars made with buttons, aren't really that nice when you see them for the first time...
Binaries available?
Are there any binaries available? Current svn doesn't compile for me because of problems with debians' mozilla-dev packge. I'd like to give aspeditor a try.
Thanks
I'm afraid not
I can build you AMD64 binaries for Ubuntu Breezy, or anything with the same ABIs, but I don't have a cross-compile process set up. While the CIL code will even work on .NET, the C++ glue code - for which the Mozilla-dev package is needed - needs to be built against a specific Mozilla.
When the project is integrated into MonoDevelop and we release it properly, we will of course have binaries for all supported platforms.
I had a look at the source
I had a look at the source again and it doesn't compile out of the box on debian x86. The build/ and build/lib directories aren't created by the makefile. After patching some stuff in the source files it compiled but I don't get it to find its chrome.
Thanks for the feedback.
Thanks for the feedback.
I'll fix up the config file to make the build directories later.
Did you install the editor (sudo make install)? That's the way the chrome is deployed into the Mozilla directory - maybe I should add a "deploy-chrome" make task for those who want to use "make run" instead of a complete install.
If not, does ./autogen report the correct Mozilla dorectory?