jfrazierjr wrote:
The problem here is how will Maptool know anything about your game system X? At the end of the day, this is what user created frameworks will be for and you can use them now if someone has taken the initiative to create one (or more!!) for your specific game system.
This doesn't need to be system-specific; basically what I'm proposing is to allow players to add as many attributes to the tokens they own as they want, and these attributes would act like campaign-wide attributes (i.e. they would be reference-able in macros). The GM would be able to enforce campaign-wide mandatory attributes so that campaign macros work, but otherwise, players would be free to use their token's attributes to store whatever they want--eye color, gold pieces, inventory lists, whatever. There would be a dedicated pane for the attributes of the selected token so that they could edited quickly. The idea is simply to reduce the number of times that I have to switch to Notepad/Excel/pencil+paper to jot down some minor item like "turn undead will last for six more rounds". I'm aware that this is probably more than a cosmetic change.
Phergus wrote:Chrest wrote:Dragging the map should be left-click, not right-click.
No. As already pointed out thousands of users already know the interface but in any case MapTool has both display and drawing functionality. How are the players and GM going to use the drawing tools or do boundary select of tokens? How often is the GM going to accidentally move map tiles when she wanted to pan the map? The current system allows you both to pan and draw.
Leaving aside the issue of whether it's better to make the program more accessible to new users or to preserve the idiosyncratic learned behavior of veterans, you are right that being able to pan and draw at the same time is valuable. But this fact alone doesn't mandate that panning be assigned to right click; below is an alternative mode of interaction that allows panning and drawing, but assigns panning to left-click.
Drawing: Play around with the Google Maps Distance measurement tool. It uses left-click for both drawing lines and for panning the map, and I've rarely, if ever, panned when I wanted to draw or vice-versa. MapTool is a bit more complex because some drawing tools, like the circle, square, and freehand tool, currently require you to hold the mouse button down as you draw, which looks like a drag. However, this can be solved by toggling the tool on after the first click, and off after the second. Click once to begin your circle/rectangle/freehand line, move the cursor, click again to finish drawing. I actually prefer this mode when a program supports it--moving the mouse without holding down a button is more comfortable--and it's intuitive because it provides immediate feedback.
Boundary select: Have them hold down the Shift key, and change the cursor icon when they do so to let them know they're in boundary-select mode. Shift-clicking is probably how most people will try to select multiple tokens the first time anyway, and once they see the new cursor, they'll realize they can just drag a selection box. Sure, it's a tiny bit more difficult to hold down Shift, but I'm reasonably certain that most people pan the map more often than they boundary select tokens, so I think panning should be the easier to accomplish among the two (and no, right click for panning is not as easy to accomplish as left click, because right click means, in practically every other program, as well as elsewhere in MapTool, "modify what I'm clicking on". Using it to pan is non-standard and will be a surprise to most people, in my opinion).
Map tiles: Require a 1.5-click to move map tiles. If the user clicks on an unselected tile and drags, the map will move. If the user clicks on an unselected tile, it will be selected, and the cursor will change to the crossed-arrow drag symbol while hovering over the selected tile. If the user clicks and drags on a selected tile, it will move.
I'd also like to point out that right-click-to-pan is a pain for Mac laptop users specifically, because right-click is usually accomplished via two-finger click on the trackpad. But two-finger drag on a Mac laptop is the scroll wheel, so a Mac laptop user trying to pan the map will end up zooming in and out until they realize that they have to use Command-Click. Obviously the program shouldn't be modified to fit the needs of one group of users, but if there is an alternative interaction method that works equally well for all platforms, I think it should be preferred.
If these address your concerns, then we need to look at the issue of whether it's better to stick with what current users know, even if it is baffling to new users, or to switch to what the new users expect. I don't think there's any question that MapTool should cater to new users.
First, veteran users aren't likely to leave if you change the interface (unless you do it constantly). They've already managed to learn MapTool despite its high learning curve, so they're more willing than most to learn an idiosyncratic interface. They're also invested in MapTool because they're probably using it to run campaigns, and even learning a significant interface overhaul probably wouldn't be as much work as switching to a new VTT system. The new interface will probably be easy for veterans to learn anyway, because it will make MapTool more like other programs they already use, so it's a matter of forgetting their old habits rather than learning a new interface from scratch. At the very worst, veteran users will just stick with the version of MapTool they're comfortable with.
Second, new users are very sensitive to high learning curves; I don't know how many potential users MapTool scares off by having a quirky interface, but I'm pretty sure that it's a significant number. My group would never have gotten off the ground if both I and my GM weren't willing to watch the tutorial videos and spend a lot of time learning MapTool's interface--the rest of our group needed a lot of handholding before they felt comfortable with it. The overlap between computer geeks and roleplaying geeks is probably significant, but it is by no means perfect, and it makes no sense to cut out those people who aren't both. By doing so, you're missing out on the contributions they could be making to the RPTools community, just to save the veteran users the trouble of spending a few minutes learning a new mode of interaction. It doesn't make sense to me.