Viewer redesign
From SkyOS
Contents |
SkyUI Concept
The following is an overview of a concept for a possible graphical user interface for SkyOS
SkyOS Viewer Mockup: Search area collapsed
SkyOS Viewer Mockup: Search area expanded
The elements shown in this image include desktop icons, application panel (including application launcher and application dock), SkyOS control menu, and SkyOS Viewer (including various sub-elements).
The desktop icons are standard desktop icons, which can launch an application, and can be manipulated in various ways (cut, copy, paste, properties, etc).
The application panel includes the application launcher and application dock. The "launcher" functions as a quick means of launching commonly used applications. The various shortcuts are added by the user by dragging the executable file into the area where the launcher resides. The application dock serves as a dock for already running applications. This area starts with no items, and fills up as applications are launched. When an application is exited, the icon disappears from the dock if that is the only instance of the application remaining running. Various aspects of the application can be controlled by accessing the items in the dock (minimize, exit, etc).
In between the application launcher and application dock is the SkyOS menu. This will have multiple functions, such as accessing shortcuts, files, etc (needs to be better defined).
The SkyOS Viewer consists mainly of four quadrants: Preview, Filter, Folder View, and File View.
Preview simply allows users to preview a file that is selected in the file view. This includes image, music, video, and document files. Other previews may be possible in the future through use of extending plug-ins.
Filter allows users to filter only certain file types in the File View window. For example, if "Images" is selected, only image files (ex: bmp, jpg, gif, png, etc) will be visible in the File View window. Users may add a custom filter for commonly-needed file formats.
Folder View only shows folders. Unlike other common file browsers, which usually show both folders and files in one view, the SkyOS Viewer would show these types of items in two separate windows. When a user accesses a folder, the contents of that folder are split, with folders appearing in the Folder View. The path taken to get to the parent folder is also shown, and may be accessed to quickly move to a different parent folder.
File View, like folder view, only shows one type of item, files (folders are found above, in Folder View). Files in the File View may be accessed and manipulated like most other file browsers. Items may be sorted by different means, such as name, date created, size, etc by clicking in the area above the files (not visible in picture).
Other elements: There are other elements of the proposed SkyOS Viewer. These include the maximize button (top left green button), minimize button (bottom right blue icon), and close button (top right red button). Additionally, the name of the application (SkyOS Viewer) is listed at the top. The window may be moved by clicking and dragging and gray area above the starting line of the Preview and Folder View. The window may be resized in one direction by clicking and dragging the left/right/bottom gray border, or in both directions (horizontal and vertical) by clicking and dragging the bottom left/right corners.
Colors
I like the concepts, they're really well thought out. But can we change the color, please? Gray. Yuck. --zizban
I think the hope would be that most of the colors/gradients could be customized by users. - Kelly
Robert
Actually, I have a few problems with this design.
1. The favorites
This layout is problematic when resizing the window horizontally. Either all "buttons" must be resized, a gap must be inserted or the location changes.
Kelly
I think you're referring to the black/white buttons above the folder chain, is that right? If so, these are actually the tabs, not the favorites (sorry, I'll get around to writing up the explanation). :) The favorites are that icon on the folder chain bar. You click it and a window flies out.
My thinking was indeed that the tabs would get stretched (or if there are hidden tabs, more would become exposed). I know that means more redrawing occurring, but I figured I'd just throw it out there. - Kelly
Robert
Ok, got it. Btw, as the Viewer will only use SkyOS "standard" controls, like a TabView, this would mean that all tabs in every other application will look like this. Is this intended?
2. Search results
I don't like two seperate views for folder content and search results. One of the biggest BFS features are queries, which in BeOS act like a normal folder. SkyOS has this too, and indeed is used already with the current search buttons which can simply be moved to the favorites now. (opening a search result when clicking such a query can be implemented rather easy too). Additionaly, you can perform the exact same actions on search results as you can on folder content. Why should we use two separate views for the exact same possible actions?
I think this would still allow for that. If you search in the search area below, results come up, be they files or folders. If it is a folder, you could simply drag it to the area where the tabs are, and open a new tab with that folder. Also, files or folders that show up in the search results should have the same context menus as they would in the folder or file view windows. The file and folder view windows are simply a different way of presenting what we already have in the Viewer. Instead of being in one window, they are in two. I honestly thinks this makes the great query system you have going, even more feature complete and powerful! =) - Kelly
What I actually like about the design
is the folder chain. This is very useful.
3. The folder view
I'm not really sure if I like a separate folder view and see a few possible problems there: (looking at it from a developers point of view how has to often and quickly navigate through files and folder trees)
- lot of files and folder
If you want to open a file or folder starting with 'z' for instance, you will have to scroll two views just to get to the last files and folders.
This might actually be faster. Usually, items are arranged all folders first, then all files (I forget if SkyOS does this, I'll have to boot and see). Anyway, with the "Z" example, you are generally looking for either a folder, or a file. You'll know right away which pane to look in (i.e. top if it is a folder, bottom if it is a file). So depending on what you are doing it might either be almost exactly the same time/effort, or it may actually be less. I think we'd need to implement it and try it out to know for sure. - Kelly
- multiselect
How to remove folders and files in one operation? e.g. selecting two folders and three files, trying to delete them at once, which will not work here.
I think that, if possible, the user should be allowed to select items in both panes at the same time. Robert, you brought up an interesting scenario in IRC, wherein someone may accidentally delete an important system folder because they did not know that they had selected it. I think to help prevent against this, by default, the function should work as such:
- If you select a folder (in folder view), and then try to select a file (in file view), then the folder is de-selected, and the file is selected.
- Conversely, if you select a file (in file view), and then try to select a folder (in folder view), then the file is de-selected, and the folder is selected.
- If the user holds down the "Control" key on the keyboard, then they can select multiple files, including items from the folder or file views. This will be the only way to have items selected from both panes at the same time.
The only argument here is that someone could have held the Control key down and selected a folder, and then files, and then accidentally delete the important folder, but really, what is stopping them from doing that now? More importantly, it is likely that the last thing visible in the folder view would be the folder they accidentally selected, in which case they could have a visual cue that it is still selected. This is not the case in current file explorers (where the folder would likely be selected, and after scrolling down to select files, would be out of view). - Kelly
Resize
Where and how do you resize the various views?
- How to resize the search results view? What is the initial size? (A search may take a while, so precomputing the sized based on the results will not work)
- How to resize all other parts?
I haven't added function yet for resizing the views, but it would be similar to how it usually works in file browsers (some icon in the middle region to drag).
A search would have to start with enough space for a certain size that we will have to pick (as far as I'm concerned, an arbitrary number, say enough room to display ten results). I think we would need to add a button at the bottom (under the search results) that would allow you to resize the search area.
The main window of the Viewer is currently designed in the mockup to only be resizeable by the icon in the lower-right; clicking and dragging anywhere else will either simply move the window, or resize a sub-window in the Viewer window. - Kelly
New Viewer functionality: Image::viewerquery.png Image::Viewerquery.png Image::viewerquery.png Image::-Viewerquery.png
