Re: [Rails-devel] Fixes & sorting

[brett l. <wak...@gm...>]

On 6/24/07, Erik Vos <eri...@hc...> wrote:
> > > > Ahhh...   how about we relabel it as "Master Undo (for testing)" ?
> > >
> > > Hmm, isn't that a bit longish?
> > > I was inspired by the vi commands that get a forcing character when
> > > suffixed with a !, for instance q! forces quit where q doesn't.
> > > I agree that some explanation is needed, perhaps a tooltip?
> > >
> >
> >
> > A tooltip would help, but in general having two menu options named the
> > same thing is going to be confusing.
> >
> > I don't really see a problem with a long menu option. We're not
> > limited for space there.
>
> Actually, I meant that the appearance of two options is temporary.
> ultimately, I think there would be only one undo option (labelled just
> "Undo"),
> and it would depend on the user's role (player or Master/Moderator) what
> its meaning would be.
>
s> For now I suppose we have two ways in which the program can be used:
>
> 1. "Hotseat", which (if I'm right) means that players take turns behind one
> screen.
> In that case, the (restricted) player undo would apply.
>
> 2. Moderator, in which case one person replays or moderates a game.
> In this case the unrestricted version would apply.
>
> What about adding a startup option (two radio buttons?)
> to select between these two usages? Then the "Undo!" could go.
>

Here are some other ways we could do it:

1) We could add a new temporary drop-down menu for testing new
functionality, and just enable/disable it this new menu with a
"development mode" startup option.

2) We can move the "player undo" back onto the game status window,
next to the Done button.  Then rename the Move menu to something like
"Moderator", so that the Undo that's in there is more clearly a
"Moderator Undo"



I like #1 because then we can add anything in there without worrying
too much about choosing a permanent position within the UI for it.
This also allows us to have these potentially confusing UI elements
disabled by default when we ship out new JARs.

I like #2 because it creates a clear differentiator that may be useful
for other features and could be a less temporary (more permanent) way
of presenting that feature.



At this point, it doesn't *need* to be fixed right away. We can simply
disable it if there are enough other things that have changed to merit
a release.


---Brett.