vassalengine.org • View topic - Community issues and Documentation forum section

Page 2 of 3

Community issues and Documentation forum section

Posted: March 6th, 2008, 11:21 pm

by uckelman

Thus spake "meng":

Another thought - since a common complaint I read is that the VASSAL interfac
e is not intuitive (*cough* BS *cough*) - perhaps we could come up with some
sort of personal tutor schedule?

Are they ever more specific than that about *how* they find it unintuitive?

--
J.

_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)

Posted: March 7th, 2008, 12:22 am

by bsmith

meng wrote:Another thought - since a common complaint I read is that the VASSAL interface is not intuitive (*cough* BS *cough*) - perhaps we could come up with some sort of personal tutor schedule?

It's improving thanks to the guy's work on newer releases.

There are still problems that need to be addressed such as crazy multi-sized toolbar buttons, no standardised shortcut keys, zoom in and out not centring, no auto-scroll when moving the mouse near the map edge etc. Pretty much a heap of stuff users are very accustomed to from playing real time strategy games.
My own thoughts on this issue are that we must enforce a consistent interface design through the Vassal editor.

Just a few examples, I could rant on about this for 30 pages

- The editor should not let people change the shortcut for deleting a piece from Ctrl-D to Ctrl-F. Ctrl-D should be permanently reserved. Changing the shortcut keys for these should be a user preference only, if we choose to allow it at all.
- *Every* piece in every module should be forced to have a few traits which are standard, like Delete, label etc.
- Every map should have Zoom, Snapshot and Hide Pieces by default.

Posted: March 7th, 2008, 12:52 am

by Tim M

bsmith wrote:My own thoughts on this issue are that we must enforce a consistent interface design through the Vassal editor.

Just a few examples, I could rant on about this for 30 pages
- The editor should not let people change the shortcut for deleting a piece from Ctrl-D to Ctrl-F. Ctrl-D should be permanently reserved. Changing the shortcut keys for these should be a user preference only, if we choose to allow it at all.
- *Every* piece in every module should be forced to have a few traits which are standard, like Delete, label etc.
- Every map should have Zoom, Snapshot and Hide Pieces by default.

Please NO!

This was my exact problem earlier when Thomas brought it up which turned out to be not his intent and I hope its not yours either

Enforcing key standardization removes flexibility the engine allows.
What if the piece is not supposed to be ever deleted and is an At start stack and does not reside in the palette tray?
Oops I accidently hit delete and didnt notice till later - there goes my piece and there goes my game - got to start all over again because you mandate that every piece must have a delete trait :roll:

What if you dont use labels?

Why do I have to have zoom on my map if it is full size and everything is perfectly clear due to graphic size?
Think through what the ramifications could be please...

Again - the open ended nature of the engine is what makes it superior to other utilities. Cut it down with restrictions and BS requirements and it becomes no different than any other similar utility and loses its edge

Posted: March 7th, 2008, 12:59 am

by bsmith

I do disagree on this point, I would rather sacrifice flexibility if it means we can increase Vassal's widespread use. Flexibility with a narrow user base or usability for the masses?

Our opinion differs, I'm cool with that.

Posted: March 7th, 2008, 1:28 am

by bsmith

Tim M wrote:What if the piece is not supposed to be ever deleted and is an At start stack and does not reside in the palette tray?
Oops I accidently hit delete and didnt notice till later - there goes my piece and there goes my game - got to start all over again because you mandate that every piece must have a delete trait

I don't understand this point, the only module I've used without a delete trait on counters was the CC:E module; I remember dragging a piece to the board when I first tried to play, then being driven nuts when I couldn't get rid of it, that was the last time I used that module. I've played hundreds of games on Vassal, never had this problem. Every piece should be in the palette, I don't understand why you would not do that?

Tim M wrote:What if you dont use labels?

Doesn't matter, why not have the feature there anyway? There are thousands of apps which have shortcuts nobody uses.

Tim M wrote:Why do I have to have zoom on my map if it is full size and everything is perfectly clear due to graphic size?
Think through what the ramifications could be please...

Maybe your eyes are younger than some people? Older or visibly impaired may need to zoom in.

Community issues and Documentation forumsection

Posted: March 7th, 2008, 1:34 am

by Tim M

Ok, forget gameplaying ramifications then and let's talk masses then if you
think that's more important and your reasoning why to do it.

Discount/remove the mods that use flexibility which probably extends to a
good 50% of them and you've got no masses!

Also I'd like to point out that you sacrifice flexibility IF it increases
use. That's a big IF you're hanging on there. What IF it doesn't increase
use but redacts it? Now you've totally hosed things the opposite way. Not a
very good idea

I am fine with if you want to enforce it on your mods, even remake those
that don't adhere if you want, but don't enforce it on any one else that
wants to make them.

This only serves to discourage mod development and no one need bother do it.
Better yet -
We could just assign a couple people the responsibility to make modules,
have them conform to the 'standards' you bestow us and remove the module
editor all together then - gee what fun module making will be for someone if
we leave it in otherwise?

Post generated using Mail2Forum (http://www.mail2forum.com)

Posted: March 7th, 2008, 1:48 am

by bsmith

I'm not trying to impose anything here Tim, relax dude. I'm just discussing our options.

When people say "Interface is not intuitive", this sort of stuff is what they're talking about. I'm just opening up some discussion on how we can retain flexibility, but make it more intuitive at the same time. If it needs to stay unintuitive, that's fine, I just want to talk about the reasoning behind it being the way it is.

Community issues and Documentation forum section

Posted: March 7th, 2008, 2:06 am

by Brent Easton

Just a few examples, I could rant on about this for 30 pages
- The editor should not let people change the shortcut for deleting a
piece from Ctrl-D to Ctrl-F. Ctrl-D should be permanently reserved.
Changing the shortcut keys for these should be a user preference only, if
we choose to allow it at all.
- *Every* piece in every module should be forced to have a few traits
which are standard, like Delete, label etc.
- Every map should have Zoom, Snapshot and Hide Pieces by default.

I think this is where the 'Vassal Human Interface Guidelines' document comes into play where we can suggest a standard people might like to follow.

_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)

Community issues and Documentation forum section

Posted: March 7th, 2008, 10:58 am

by uckelman

Thus spake "bsmith":

There are still problems that need to be addressed such as crazy multi-sized
toolbar buttons, no standardised shortcut keys, zoom in and out not centring,
no auto-scroll when moving the mouse near the map edge etc. Pretty much a h
eap of stuff users are very accustomed to from playing real time strategy gam
es.

Expect a fix for the buttons and zoom centering in 3.2.

My own thoughts on this issue are that we must enforce a consistent interface
design through the Vassal editor.

I think we should set the defaults according to a standards document
we work up, but still permit them to be changed. For the most part,
designers won't change the defaults if the defaults are well-chosen.

Just a few examples, I could rant on about this for 30 pages
- The editor should not let people change the shortcut for deleting a piece f
rom Ctrl-D to Ctrl-F. Ctrl-D should be permanently reserved. Changing the s
hortcut keys for these should be a user preference only, if we choose to allo
w it at all.

If there's a standard shortcut for deleting a piece, it should be Delete,
not Ctrl-D.

--
J.

_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)

Posted: March 7th, 2008, 2:36 pm

by meng

While I think it's fine to improve the interface, etc., my point was really that because of a perceived difficulty in using VASSAL (regardless of the reality) we should come up with strategies to overcome that perception.

Now, one strategy is changing the "reality", i.e. improving the interface, and I certainly agree that various components of VASSAL could do with some standardizing, although I think the overall effect of that will be relatively minor apart from assuaging some OCD and giving a slightly more polished/professional appearance.

Another great strategy is documentation, which I have volunteered to take responsibility for, and not produced a great deal yet, admittedly, although I was hoping for some other volunteers to assist, well we can't get everything we want, right? Anyway, new documentation is still on its way.

Thirdly, and fitting in with the idea of "building community", is hand-holding. My dream is to show a few potential users (who would otherwise be scared off by the anti-VASSAL propaganda) that it's actually not too difficult to use at all, then the word will spread and users will flock to VASSAL. Now, it's a time-intensive approach, and perhaps there are other more creative and workable suggestions out there.

So go ahead and debate how the interface should be tweaked, but if you don't mind, give some thought to the other side/s of the equation.

Community issues and Documentation forum section

Posted: March 7th, 2008, 2:40 pm

by mkiefte

Just to throw my 2 cents in here, enforcing restrictions is bad. Handholding is good. We definitely do not want to get away from the flexibility that VASSAL provides. That being said, there are some really ugly modules out there and a lot of these complaints have to do with the modules themselves, not the engine.

- M.

On 07/03/2008, meng <messages@forums.vassalengine.org (messages@forums.vassalengine.org)> wrote:

While I think it's fine to improve the interface, etc., my point was really that because of a perceived difficulty in using VASSAL (regardless of the reality) we should come up with strategies to overcome that perception.

Now, one strategy is changing the "reality", i.e. improving the interface, and I certainly agree that various components of VASSAL could do with some standardizing, although I think the overall effect of that will be relatively minor apart from assuaging some OCD and giving a slightly more polished/professional appearance.

Another great strategy is documentation, which I have volunteered to take responsibility for, and not produced a great deal yet, admittedly, although I was hoping for some other volunteers to assist, well we can't get everything we want, right? Anyway, new documentation is still on its way.

Thirdly, and fitting in with the idea of "building community", is hand-holding. My dream is to show a few potential users (who would otherwise be scared off by the anti-VASSAL propaganda) that it's actually not too difficult to use at all, then the word will spread and users will flock to VASSAL. Now, it's a time-intensive approach, and perhaps there are other more creative and workable suggestions out there.

So go ahead and debate how the interface should be tweaked, but if you don't mind, give some thought to the other side/s of the equation.

Post generated using Mail2Forum (http://www.mail2forum.com)

Re: Community issues and Documentation forum section

Posted: March 7th, 2008, 4:47 pm

by meng

mkiefte wrote:Just to throw my 2 cents in here, enforcing restrictions is bad. Handholding is good. We definitely do not want to get away from the flexibility that VASSAL provides. That being said, there are some really ugly modules out there and a lot of these complaints have to do with the modules themselves, not the engine.

I would only be interested in showing off the best that VASSAL has to offer, no point wasting time on the ugly and unfunctional. A small proportion of users may then be inspired to go and improve the other modules (although I wouldn't hold my breath waiting for that to happen).

Community issues and Documentation forum section

Posted: March 7th, 2008, 5:35 pm

by tar

On Mar 7, 2008, at 8:47 AM, meng wrote:

I would only be interested in showing off the best that VASSAL has
to offer

So, should there be some sort of awards show? A way to recognize
really nicely done modules?

Perhaps call it the "Order of the _________", to play off the Vassal
theme, with some Academy Award like categories:
o Best original artwork
o Best automation
o Best overall design

_______________________________________________
Messages mailing list
Messages@forums.vassalengine.org
http://forums.vassalengine.org/mailman/ ... engine.org

Post generated using Mail2Forum (http://www.mail2forum.com)

Community issues and Documentation forumsection

Posted: March 7th, 2008, 6:05 pm

by Tim M

I think we tried this idea once before but it never got traction.
Without any award guidelines and qualifying criteria laid out beforehand
though, this would probably just end up being a popularity contest of mods
by user base

Post generated using Mail2Forum (http://www.mail2forum.com)

Posted: March 7th, 2008, 6:27 pm

by meng

I suppose the question is what you're trying to achieve by recognizing good modules - a "fair" process of acknowledging what is truly best, or a way to generate more excitement and interest in VASSAL in general.

One could argue how useful the tournament/ladder module is in identifying the truly best players, but unarguably it generates some interest and excitement in VASSAL.

My comment about showing off the best was in relation to being a volunteer live VASSAL tutor, showing folks how to do PBEM and real-time play using one of the better modules which demonstrated good design. But I'm pleased that my comment generated at least one idea (even if it wasn't entirely original).