nightflyer wrote:My ideas are:
-It is possible to put just icons in tree panel, not icons with names, like here: http://www.pspad.com/img/screen/mainfull.png Now you have easily place for 5 or 6 tabs. You can display tab name in tooltip (balloon) if needed. If user makes tree panel very narrow, he just gets two rows of tabs.
Yes, i can use only icons
-Sidebar headers take too much useful space!
-Joining items in tree is bad and not useful. If there are some more items and/or expanded branches, I cannot see two kind of items anyway. Then, if I want to precisely navigate with tabs, I just click tab header and in big tree I have to scroll and look for.
So you think that i must not join Favorites & categories?
But if i want to add Rating, add a panel only for that is not good, so i have to put it on same pnale as categories...
Categories, Color ratings (if you decide to add them, like in Adobe Bridge), Number ratings and Tagged can be put into one tab, as they all similar- to assign user-chosen characteristic to file. They differ just in the way the characteristic are assigned. And you can easily search with checkboxes next to item names (like all 1-rating photos of a dog).
I think also that if user assigns Ratings or Tags a file, an automatic Category should be created.
On the other hand, Favourites and Folder are a way of navigating folders on the disk, as opposite to navigating user-chosen characteristics.
I think that:
-it should be one tab for Categories/Ratings/Tags and second for Folders/Favourites. It should be the final solution
-if it is too hard now to put Favourites into Folder, I accept Folders and Favourites/Categories tabs but as a temporary for the next version
-there is no need for separate tab for Ratings
It is important to enable navigating to other tab with drag and drop!
Icons "only" in tabs works for me, but not necessarily for a newbie. I use (and have written) quite a bit of software designed like Nightflyer's screen shot and like the interfaces OK. They can look a bit "dated", but are otherwise functional.
You are newbie for a short time and then all life an experienced user
I don't like sacrificing something to make first half hour of usage easier.
Standard user has "Windows image and fax viewer".
Once you start using categorize in XnView Alpha 3 you realize that this really needs to be improved:
You have to switch from folders to categories to assign an image to a category, but as soon as you happen to click on "+" of a main category to open a category for seeing its sub categories, your files will no longer be shown since the main categorie's contents are shown.
Handling of categories would be much easier if categories, folder tree, and files would be visible at the same time. One way to achieve this is a tree which contains both categories and folders (as discussed above). A second option would be separating the assignment of categories with the navigation in categories like it is in XnView DeLuxe:
The "Categories" on the left are for navigating the categories and seeing their contents. The "Categories" panel at the bottom is for assigning categories to files, only.
The combination of category assignment and category navigation in one tree is appealing, I think, but it bears problems which we have to be solved.
- Checkboxes
Dragging & Dropping images onto categories is intuitive once you know about it, but checkboxes are a better and clearer indication. So I support the usage of checkboxes.
- Tabs with icons
I think tabs with icons (suggested by nightflyer) are a good solution as long as there are not too many (>5 tabs). Tooltips might help to understand the meaning/function of each tab.
Note: I haven't read this whole topic thoroughly, so please excuse if these aspects have been mentioned before.
nightflyer wrote:-Sidebar headers take too much useful space!
I probably don't agree with this. Here's why:
1. Sidebar headers can be rotated 90 degrees to take up less space. Many softwares use this technique. Here is how tabs look in PaintshopPro. PSP allows panels, uh, "palettes" to be docked to any window border and collapsed to a tab when not needed. I have docked (and minimized) some panels PSP on the right window border in the following image:
2. Most screens have more horizontal pixels than vertical pixels (unless rotated, of course) and most new LCD screens are 16:9 proportion instead of 4:3. My screen is 1920x1200... plenty of room for sidebars on both sides!
JohnFredC, but I do not uderstand why you want to take away data-space? Just for nice-looking? "Vertical" buttons still take a few times more space than icon-only tabs.
helmut, some very good questions.
-When you assign categories, navigation problem may be when you categorize many folders with small numbers of files each. Then and only then you need intensively navigate between distant folders, what you do with folder tree. This is rare I think. People (also me) put photos in order, in one or a few places. The secondary toolbar is enough for navigation then.
-Adding second categories tree is adding to confusion.
-Jumping to category when expanding tree and no auto expanding tree when assigning to category are bugs. I could not think these features are put on purpose.
-These also add to my other post:
--Assigning with checkboxes is really good. If we want checkboxes to Search as well, we have to find a solution. My advice is to add toolbar to tab like in this picture. Then you can add there switch to change to Assign or Search mode and other options from this post. In Assign mode checkboxes are used to assign, not to search. All options can be also put in context menu, but I think small toolbar is much more comfortable.
--If category is already assigned to image it (icon or category name) has different color. This way you can use Search mode and at the same time assign images with DnD.
--I hope it is clear?
2NightFlyer
There is a trade-off between data space (on the screen) and control space (on the screen), especially for mouse users. Sometimes, ease of use considerations can favor control space (ie. larger or more controls visible). I like your proposal, though, as I said previously. I too am conscious of "wasted" screen real estate and think that should be minimized.
2Helmut
Those two category panels are confusing as portrayed, but I think your point is: Sometimes control and data display redundancy is unavoidable. It is important to distinguish between using a category (or tag, or album, or whatever) control interface for selection of files vs.assignment to files.
Possible task flow scenarios with categories (or tags or albums, etc):
[1]
Navigate to and select a file or files (using any method)
Display file properties (showing category membership)
Assign/reassign category
[2]
Select category/categories
Navigate to folder
Files in folder that match category/categories appear in file list
[3]
Select category/categories (no folder tree selection)
All files matching category/categories appear in file list
Deselect category/categories: WHAT HAPPENS?
There are many permutations. It might benefit the discussion to add to this list.
In my business (database engineer) the data stucture is modeled first, then the control surface needed to locate/filter/modify that data is designed in response to the characteristics of data structure... Working "backwards" from the user interface to the data rarely works.
We tend to think of the file system as a container for files, with the file conceptually subordinate to the folder. This is forced on us by the "standard" folder tree navigation paradigm in which we first select a drive/folder and then a file and then view its contents:
This the way XnView works now. But if you think about it abstractly, the folder location of any file is just another property of the file itself, a peer of all the other data about the file. It's just maintained/stored externally to the file, not inside the file itself.
A file's properties ("attributes" in data structure parlance) include:
ATTRIBUTES OF A SINGLE FILE
-1. "File system" derived attributes/metadata:
---> File path (drive, folder, etc.)
---> File creation date, read/write flags, etc
-2. Binary content
-3. Binary content derived attributes (type: jpg or bmp., etc, dimensions, etc.)
-4. Internal metadata (EXIF, IPTC, etc.)
---> EXIF
---> IPTC
---> Etc.
-5. "Selection and grouping" derived metadata (tags, categories, etc)
Notice:
#1 are data stored & maintained "outside" of the file (by the file system)
#2 & 3 are data stored & maintained "inside" the file (by XnView or other tools)
#4 are data stored & maintained "inside" the file (by XnView or other tools) if possible
#5 are data potentially stored & maintained both "inside" AND "outside" the file (by XnView or other tools) if possible
Regardless of where the data physically resides it all belongs to the file and is part of that file's "virtual" data structure.
So a "virtual" paradigm useful for work flow within XnView's interface should also (not instead of) consider the folder tree as subordinate to the selected file(s) in the control and panel design... in other words, the folder data might beneficially be combined with the other peer data about the file into a single navigation tool, whether that tool is a tree, a form, or what have you.
That way, I could use the following work flows:
Select Category->Select Folder->Select File->View file
Select IPTC Field Value -> Select Files -> Select File System Date -> Display Folders
This is similar to what Picasa tried to do in Version 1 of its sidebar tree (but which did not have a system folder tree). It failed because an individual file's file system folder location is of equal (not greater, not lesser) conceptual importance to Category or Rating. Picasa 2 now includes a file system folder tree as a peer to Categories ("Collections") and albums. Picasa still doesn't have the merged tree thing quite sorted out (no drag and drop between folders and categories for assignment purposes), but it's getting there.
Whew! Sorry for so many long-winded posts. This stuff is hard to communicate clearly!
Four tabs in the Navigator. Each tab's panel would have a toggle control labeled "Also Select" to enable automatic selection of the files (in the File List Panel) that match critieria specified in the active tab.
Navigator Tab 1: File System Folders & Folder Favorites
Combine the Folder Tree and the Favorites tree into one panel with a variable splitter between the two trees. A user could select a Favorite or a folder in the system folder tree and the appropriate folder's files would appear in the File List Panel. A user could also drag a folder (or perhaps a file?) directly into the Favorites tree to create a Favorite.
Navigator Tab 2: Quick Organizer
One panel with separate (perhaps collapsible) areas for tags, qualitative values (stars or ratings for instance), and other XnView maintained organizational metadata (categories, albums, collections, or whatever). Tab should expose controls to manage the metadata (delete, add categories, etc). A user might also drag a file or files from the files list into a category or album on this tab. If this tab was not the current one, hovering the mouse pointer over the tab would switch to it, allowing the user to then drop the selection on a category or whatever.
Navigator Tab 3: Filters
A panel containing a folder tree or list of user filters plus controls to manage filters and display a filter definition dialog (similar to the Options dialog) that would allow complex filter definitions, including those based on metadata (Categories etc.), EXIF, IPTC, and other values. Selecting a filter from the tree or list would show the matching files in the File List Panel.
Navigator Tab 4: History
A panel showing a list of folders, favorites, filters, etc., recently navigated to or applied. Selecting an entry from the list would show the matching files in the File List Panel. Tab should have controls to manage history entries.
Panel 2: File List/Thumbs Panel
As now in XnView Alpha 3.
Panel 3: Preview
As in previous versions of XnView: image only, no tabs.
Or perhaps: two panes with a splitter, one pane for the preview image, and one pane for the histogram. (...though I personally don't need the histogram in the browser at all.)
Panel 4: Properties Panel (new)
Several tabs in the Properties Panel:
Properties Tab1: General & Calculated Image Properties
Equivalent to current Properties tab of the Alpha 3 Preview panel.
Properties Tab2: Quick Organizer Data
A data form: Use to assign tags, ratings, stars, categories, whatever to the files selected in the File List/Thumbs panel, this is like Helmut's "Categories" panel (see his previous post) but expanded in content and function.
Properties Tab3: EXIF
Equivalent to current EXIF tab of the Alpha 3 Preview panel.
Properties Tab4: IPTC
Equivalent to current IPTC tab of the Alpha 3 Preview panel.
Other tabs as required in the future.
VIEWER
Three Panels in the Viewer, with new-style splitters:
Image Panel
Properties Panel (same as properties panel in the Browser, but only showing properties of image in current viewer tab.)
Tools Panel (Brightness, Contrast, Effects, etc).
OK, that's it for now. Thanks so much for everyone's patience for at least reading these very long posts. I'll finally shut up for now and hope for feedback!
You may have a look at my own attempt, 2 years ago, although more focused on Categories Management (check the last update).
I support the Physical vs Virtual Navigator Panel, with tabs.
I would prefer to keep 3 Panels instead of 4 (ie: not separate 'Properties' from 'Preview') if possible.
To assign categories/ratings/etc... I would rather see:
- Contextual Menus for quick assignment (RMB or clicking on Thumbnails icons)
- Organization Tree for more complex assignement (example: multiple categories at once)
...instead of the duplicated Organization Tree of Deluxe.
My thoughts are:
-Separate panel for preview is OK, but XnView interface is not flexible enough (like ExifPro for example) to support it.
-Better to make application around workflows not characteristics of data.
-I don't see use for Filters and History tab. We have filters on secondary toolbar. I would not use such History. Persistent and Dynamic Searches would be OK for me (Dynamic are re-searched every time they are selected, Persistent only on demand). The basis for this Searches can be extended Search window.
-Here I describe use of one Categories panel also for easy assigning with mouse-clicks (Rating and Labels assigment also possible with keyboard shortcuts- all the time).
-Assigning with context menu is questionable. They are already overcrowded.
