J. Richard Mills wrote:
>>> Also from the UI perspective: "lock" and "unlock" might not make
>>> intuitive sense to your general purpose dummy user (Audience #2 from
>>> http://svn.collab.net/repos/svn/trunk/notes/locking/locking-ui.txt).
>>> Especially since the commands actually do the *opposite* of what they
>>> claim from the user perspective. The "lock" actually changes it from
>>> read-only (i.e. locked) to read-write (i.e. unlocked) so that you can
>>> edit the file.
Eric J. Smith wrote:
>> I think that "Get Lock" and "Release Lock" are still sticking to the
>> Subversion terms, but are MUCH more intuitive.
Mark Phippard wrote:
> I do not think those descriptions are bad, I just think the simple
> Lock/Unlock are better.
There are specific good reasons for using other terms.
"I think it's better" is not really a good argument at any length :-)...
> I am sure we could come up with more descriptive
> names for all of the menu options. How about "Undo Local Modifications"
> instead of "Revert"? I am sure Update/Commit could also be "better". What
> does it accomplish?
No point in changing the entries that are perfectly fine.
> If your users cannot learn the vocabularly, setup DAV
> Autoversioning and have them just mount it as a drive.
Eg. "No point in shallowing the learning curve - if they don't get it
immediately, they're idiots, and they need to go play Tetris on a
Nintendo Gameboy."
Your suggestion would pretty much completely disable locking (except
for the splitsecond in which they're saving the file). Thus wouldn't
it be an even worse situation than the one where they don't understand
the lock/unlock words?
> People are going to use a mix of clients, they are going read books and
> help, and Google.
I'm sure they'll come up with the idea of googling for "lock", "locks"
or "locking" and not just the "unlock" word that you're missing. In
fact, I'm also pretty sure that the resources are going to mention
"unlocking" somewhere along the line, so I think it's safe to say that
Google and the docs will still work for them.
(Then again, they *are* idiots :-).. Ok, enough with that.)
> Those sources are all going to use the Subversion terms
The term locking still applies.
And I'm sure we need not fear, in the places where these sources refer
to TortoiseSVN, they're going to help the user out by calling it "Get
Lock" and "Release Lock" if that's what it's called in the GUI.
> and you are just going to make it more difficult in the long run to make up
> new terms.
Ok, now we're getting far-fetched.
> I also think it is visually easier to spot simple commands in the context menu.
You're right.
Get Lock vs. Release Lock are both two words long. Easy to spot, easy
to understand.
Even for the i...^H^H^H^H^H
We should probably do something about the current right-drag menus
though, they're horribly long.
> Just as an example, scan the Daily Use Guide table of contents. Say you are
> doing a commit and want to read about something. Now find it. You look
> and look and do not see Commit any where. Eventually it occurs to you that
> "Sending Your Change to the Repository" means commit. As a book that you
> just read, the way it is written is great. If you are just scanning for
> something it isn't.
I agree.
A lot of the topics in the help file are way too long if you want to
look anything up in the index.
It's impractical for the technical adept user who just wants to look
up one thing.
But on the other hand, the TSVN help files are über-excellent if
you're getting started with Subversion.
Really damn good reference. Definitely a must-read. For this
purpose, the titles are perfect.
> I am not criticizing the help, after all it is context
> sensitive which would make this moot.
Perhaps.
> I am simply saying that dumbing down the commands
"Get Lock" and "Release Lock" is not dumbing anything down at all.
It's just making it clear what the commands do from looking at them.
> and inventing new terms is bad.
It's not like anyone wants to call it chocolate cake or anything, it's
still "locking".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sun Apr 10 02:57:55 2005