[Greasemonkey] UI idea

Aaron Boodman zboogs at gmail.com
Tue Apr 5 10:12:58 EDT 2005


> Instead of "My Scripts", make it "My scripts"
> Instead of "Suggested", make it "Web scripts" or "Shared scripts".

Thanks. I am a moron.

> I'd like a link to the web UI for the directory, so that a user could
> hunt around for scripts without surfing the pages.  I'm hoping once
> the directory is useful, that people will tag delicious entries, and
> I'd like to be able to navigate with those.

OK, that's sensible.

> I'm not sure I understand the log section because there is more than
> one modified file listed.  When you click Test, does it modify more
> than one page?

I didn't feel like drawing it out in more detail. I figured that the
log would show the results of each script that was run on the page. In
this case, there should be three entries. Each log entry would have a
red/green/yellow indicator. If a script ran and modified the page, it
will be green. If a script ran, but did nothing noticeable, it will be
yellow. If a script ran and threw an error, it will be red. I think
there would be a GM_setStatus( ) as well so that scripts who want to
could manage this themselves.

Additionally, there would be a GM_log() where scripts could write a
simple string to the output window.

> Are people really going to code in a window that's maybe 1/3 screen
> width?  I don't have a better suggestion.  I thought about a XUL tab
> in the document window, but then you have a problem associating which
> other document the tab should be working on (and you don't see test
> results easily).

This is my number one problem with the current design; I was wonderin
if anyone would  bring it up.

In general, I am really finicky about what goes in a tab. A tab (or
window, to a lesser degree) suggests that the content really is
exclusive with whatever is in the other tab. Users would only want to
work with one or the other. In this case, I think that's totally
untrue -- you want to see your script code and the target document at
the same time.

Of course, real applications routinely violate this, so I may be the only one. 

> Just generally, I think it'd be nice to have a larger area to
> browse/code on, but I'm not sure how to accomplish this.  Maybe DOM
> Inspector's approach of having a separate window w/ an "Inject on
> this" button would work?

I was thinking of maybe splitting the page vertically instead. This
has a couple of benefits:

* more sq-inchage for GM to work with. Easier to fit buttons in and
new features.
* bigger coding area
* webpages are generally more amenable to being squished vertically
than horizontally.

And one huge disadvantage:

* It's ass ugly.

But I think in this case usability might trump beauty, so I'll give it a shot.

> For the New/Save/Save As buttons, add a tab in the space with the log
> (they won't want both at the same time).

I'm not sure I agree, for the reasons above. I see myself in this cycle:

* hack
* test
* look at log file
* rince, repeat

So having to switch tabs adds two steps on each iteration. Of course,
there might be a key binding for test, in which case, people would
always sit in log view. I'd like to try and fit the buttons on there
first though. In horizontally split, it should be easier.

* hack
* test
* switch tabs
* look at log file
* rince, repeat

Dang! going to miss bus. Gotta go :)


More information about the Greasemonkey mailing list