[Re: [gnome-love] wanted: php or cgi programmer with some spare time to help with gnome test spec]

[fflewddur <fflewddur dropline net>]

http://www.shopindiego.net/gnome_test_specs/

give it a shot :)

as far as the extra scrolling goes... a fair number of the test compents
can fit their pass/fail checks table into the upper frame, with 80%-100%
of the instructions fitting in the lower.  the main annoyance comes from
the huge titles at the top of each page, and the instructions for
setting PLATFORM, OS_VER, etc, which you need to scroll past for each
test.

todd

On Sun, 2001-12-02 at 16:44, Luis Villa wrote:
> On Sun, 2001-12-02 at 16:34, fflewddur wrote:
> > what if instead of putting the passed/failed buttons in the bottom
> > frame, we use it to display the current contents of the pop-ups?  i.e.
> > clicking on "instructions for foo01" will load foo01.html in the
> > bottom-most frame.
>
> Hrm. That would still require lots of scrolling, wouldn't it? You'd have
> to scroll both the reporting page and (frequently) the test page. The
> thing with the current setup is that it either requires lots of extra
> clicking; replacing extra clicking with extra scrolling doesn't sound
> like a great solution. But maybe it would work... it'd be hard to tell
> for sure until it was implemented.
> Luis
>
> > > Yeah, that last part is going to be non-trivial. I'd originally thought
> > > that maybe a separate page per test might be good, like:
> > >
> > > _______________________________
> > > |            |                |
> > > | navigation |  test display  |
> > > |  frame     |   (old html)   |
> > > |            |----------------|
> > > |            | 'passed/failed'|
> > > |            |    buttons     |
> > > -------------------------------
> > >
> > > for each test, selecting a test result (or 'did not perform') would
> > > store the data and bring up the next test, instead of the current
> > > monolithic perspective.
> > >
> > > The problem with this approach is that it would require either a rewrite
> > > of the cgi script to accept data in small chunks (ugly, unless someone
> > > comfortable with perl/shell has spare time) or the passing of all the
> > > data in URLs that keep getting longer and eventually gets dumped into
> > > the cgi (conceptually ugly, but maybe workable.) 
> > >
> > > Any other ideas, anyone? 
> > > Luis