I had proposed this change to the guys who run the litmus site. They had not responded, as they are in the middle of other changes. The other changes are, I think, orthogonal to these suggestions. I wanted to capture this suggestion before I lost it.
I think that this is the current structure (as I have reverse-engineered it) of the Litmus database.
I am proposing this, which I think will be much more flexible and will scale better in the long run. I am seeing a few slight errors, such as that there should be "0+" resources associated with a test, not "1+". But I think this is mostly correct.
The Category entity and its self-link allows a flexible categorization of the tests, but also allows a heirarchical categorization at the same time. The Resource entity would allow us to capture, for example, a URL as one resource of a "go to site of URL" test. Then associating 100 URLs with that test would be more flexible than creating 100 tests of the form "go to URL A", "go to URL B", etc. The Config entity would capture the type of machine and the versions of what is being run. This would be more flexible than, for example, creating a one version of test for Firefox 1.5, then a separate copy of the test for FireFox, then a separate copy of the test for Firefox 3, and so on.
If anyone has suggestions, please let me know.
Thursday, April 12, 2007
Wednesday, April 04, 2007
Correction: 2007/04/07 - This is why I like specs. I get things wrong at times. I was switching back and forth between FF and TB and wrote down the wrong menu headers. I am fixing the Firefox menu headers for Mac OS X. Thanks for the notes about this in the comments. This will be the last edit here. This document will be moved. Back to the original post....
I was telling people that this should be done, so I decided to put my feet into the dance. There is a lot of good stuff written in various blog entries and on wikis scattered hither and yon that describe various aspects of the UI of Gecko apps, such as Firefox. I mentioned that these could be brought together into some sort of specification that could be used to help people who are trying to test the product, document the product, develop for the product, or just plain understand it.
I borrowed a picture from Alex Faaborg, something I really wish I had seen in my first month at MoCo, when I was writing things in bugs that sounded like "that thing that does that stuff, next to that other thing, I do not think it is working...". Yeah. That went really well.
It is going to be difficult for one person to be comprehensive. I wanted to illustrate, though, an approach that can be taken. So, I have tried to describe the empty first page. I ended up also describing the "Quick Find" box. I think people know that command-F brings up Find, from the menu, but how many people know that the '/' key brings up the Quick Find bar instead? People remember vi, yes? Of course, they do. Very intuitive. :-)
So, here goes.
Firefox - A Browser
Of course, one does not always see these UI elements all at once. This will help more if it actually describes the state the browser is in at the time one sees this UI. While we're here, how did we get here? That is the big picture. But there are other pictures.
The first image above is the first page one sees on a Mac OS X system running Firefox 188.8.131.52 and the second is the same Firefox release on Ubuntu Linux 6.10. Obviously, there are differences between all the platforms.
- There is no Menu Bar in the window on Mac OS X. The menu bar for a Mac OS X application is at the top of the system window. The top-level menus are different.
* Mac top menus: File, Edit, View, History, Bookmarks, Tools, Window, Help
* Windows top menus: ???
* Mac top menus: File, Edit, View, History, Bookmarks, Tools, Help
- The Navigation Toolbar appears to be the same. Add-ons may place other icons in the Navigation Toolbar.
- In the Windows picture, there is a square box to the right of the Menu Bar. This is the "Busy Searching Spinner".
- The Mac has a "Busy Searching Spinner" on the right of the Search Bar. It spins when one is searching. It stays motionless while one is not searching.
- The Bookmarks Toolbar is the same.
- The Tabstrip is the same, except that the icons are different.
- The Content Area is the same. By default, the Content Area is blank. Firefix may be configured to open a page at launch. To see a blank Content Area, type "
about:blank" in the Location Bar.
- The Sidebar is the same. It is only made visible under certain conditions. By default the browser history is made visible in the Sidebar when one types the 'History Sidebar Key'. Typing key again makes the History sidebar appear. Typing this key again makes it disappear.
* Mac - 'History Sidebar Key' = command-shift-h
* Windows - 'History Sidebar Key' = ???
* Linux - 'History Sidebar Key' = control-h
- The Status Bar is the same.
- The Find Bar is the same. Typing 'Find Key' makes the Find Bar visible below the Content Area and Sidebar.
* Mac: 'Find Key' = command-f
* Windows: 'Find Key' = ???
* Linux: 'Find Key' = control-f
- There is also a Quick Find Bar that replaces the Find Bar.
Quick Find Bar:
The Quick Find Bar in a browser window on Mac OS X is shown below.
If the Content Area is not blank, typing the '/' key makes the Quick Find Bar visible below the Content Area and Sidebar. There is also an issue with the default keyboard focus. For example, bring up the page shown below and type the '/' character. The Quick Find Bar will not appear because the default keyboard focus is on the search form field. One must click somewhere else on the page to take the keyboard focus away from the form field. When there is no form field accepting keyboard focus, then typing the '/' key brings up the Quick Find Bar.
If the Content Area is blank, typing the '/' key has no effect. The Quick Find Bar disappears after approximately 4 seconds if nothing is typed.
If one types a character, it is put into the 'Quick Find' field. If there is text on the page matching the text in the Quick Find text field, then the first instance of that text on the page is selected. If the selected text is part of a link, the URL for that link is displayed in the Status Bar and if one types a return key or an enter key, then that link is activated. If one types text which does not appear on the page, the background of the Quick Find text field turns red. If another character is typed and the action does not place a text string which is found on the page into the Quick Find text field, there is an audible "beep".
For example, if one navigates to the page above and types a '/' character and then a 'xxx', the result is two audible beeps and the page below.
If one does not hit return and stops typing, the Quick FInd Bar and the text typed in disappears. If one hits the '/' key again, the Quick Find Bar appears again, but the text field is empty and the previously typed text is lost.
Still To Be Done
Absolutely everything else.