Maptool Concepts: The Next UI, Look, and Feel

Progress reports and musings from the developers on the current gaming tools.

Moderators: dorpond, trevor, Azhrei

User avatar
Notsonoble
Dragon
Posts: 387
Joined: Fri Sep 05, 2008 6:01 pm

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by Notsonoble »

So I'm taking something like a 5th shot at teaching myself Java to try and help out... and I'm noticing something odd...

If I'm reading this "Thinking In Java" stuff right... one theres not really a way to build a form visually and tie buttons/boxes/whatever to the backend code you've written...

Is that right? The reason I'm posting this here is (on top of some other things) what I'm teaching my self stuff for right now is trying to build a dummy version of some of the parts of the 1.4 UI suggestions I have in my head (it would take lots of gimp work and more than a handful of animated things to put up examples... and if I'm gonna put that kinda time into it... it might as well actually have some of the codework done too)
My D&D/Roleplaying Blog Making a new effort to update every two weeks!
Notsonoble's Samsung Galaxy S

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by Azhrei »

Notsonoble wrote:theres not really a way to build a form visually and tie buttons/boxes/whatever to the backend code you've written...
Um, depends on what you mean. There's not something like VisualBasic's double-click-in-design-mode technique unless you're using an IDE of some kind. As far as Java itself is concerned, a "form" is typically a JDialog and the JDialog must be populated with components. Java provides a way to populate the dialog by setting a LayoutManager, then sequentially adding components. If you're using an IDE, most allow for some kind of front-end to make form editing easier. In MapTool we use the Abeille form designer tool. It provides a GUI that allows the form to be developed visually, with each component given a name. That component can then be found by searching for the name. Now the Java code has a reference to the object that the user will be interacting with.

Form layout has some weirdness due to the way most desktop GUIs work, so I wouldn't start there if you're trying to learn Java. Start with the basics (variables, flow control, etc), then get a handle on the object-oriented concepts, and finally look into the GUI. The GUI is heavily OO and a solid understanding there will be needed to really grok how it works.
[...] is trying to build a dummy version of some of the parts of the 1.4 UI suggestions I have in my head (it would take lots of gimp work and more than a handful of animated things to put up examples... and if I'm gonna put that kinda time into it... it might as well actually have some of the codework done too)
Well, you might consider using JavaFX then. It's a mix of a declarative language ("Put this text box here, then place a dropdown box below it") with event handlers written in Java (mouse click, text entry, etc). It might be a faster prototyping environment. And while it's commendable to want to submit your code to the dev team for inclusion, it would probably be used more as an example of how you see it operating than as actual code that will simply be spliced into the application. It's difficult to explain without the OO background, but something that works is not always something that can be used. :?

User avatar
Notsonoble
Dragon
Posts: 387
Joined: Fri Sep 05, 2008 6:01 pm

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by Notsonoble »

Azhrei wrote: Um, depends on what you mean. There's not something like VisualBasic's double-click-in-design-mode technique unless you're using an IDE of some kind. As far as Java itself is concerned, a "form" is typically a JDialog and the JDialog must be populated with components. Java provides a way to populate the dialog by setting a LayoutManager, then sequentially adding components. If you're using an IDE, most allow for some kind of front-end to make form editing easier. In MapTool we use the Abeille form designer tool.
I have installed eclipse my understanding was that eclipse is an IDE...
Form layout has some weirdness due to the way most desktop GUIs work, so I wouldn't start there if you're trying to learn Java. Start with the basics (variables, flow control, etc), then get a handle on the object-oriented concepts, and finally look into the GUI. The GUI is heavily OO and a solid understanding there will be needed to really grok how it works.
I've had several OO classes (in C++ and C#), but aside from my visual basic class back in highschool, none of my classes ever got to UI stuff. Variables and Flow Control, i've got, Inheritance i understand the idea but by my professors said my application of it was not so great...
Well, you might consider using JavaFX then. It's a mix of a declarative language ("Put this text box here, then place a dropdown box below it") with event handlers written in Java (mouse click, text entry, etc). It might be a faster prototyping environment. And while it's commendable to want to submit your code to the dev team for inclusion, it would probably be used more as an example of how you see it operating than as actual code that will simply be spliced into the application. It's difficult to explain without the OO background, but something that works is not always something that can be used. :?
I downloaded the JavaFX SDK for this reason... and yeah I get the bit about not simply splicing in code, especially in OO vs Procedural... but even example code for visuals is better than just pictures.
My D&D/Roleplaying Blog Making a new effort to update every two weeks!
Notsonoble's Samsung Galaxy S

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by Azhrei »

Notsonoble wrote:I have installed eclipse my understanding was that eclipse is an IDE...
Correct. It does not come pre-installed with a GUI-based form editor, however. I've played around a bit with visual form editors inside Eclipse and have never been very impressed (nowhere near as nice as the MS tools :().
I've had several OO classes (in C++ and C#), but aside from my visual basic class back in highschool, none of my classes ever got to UI stuff. Variables and Flow Control, i've got, Inheritance i understand the idea but by my professors said my application of it was not so great...
Not to toot my own horn too loudly, but many instructors don't do a very good job of explaining it. Or if they do, they don't do a good job of showing how and when such things should be used.

Btw, the OO topics that are included in classes designed to teach a programming language are usually pretty worthless. I teach a 3-day (24 hours) introduction to OOA&D that covers the basics. Then there's a 2-day "workshop" class that spends the entire 16 hours creating (simplified) solutions for real world application problems while examining the full solutions to understand what the next steps would be. That's 40 hours of introductory material -- think of it as 12 weeks of a 3 credit hour college course. :) Then there's another 5-day class that covers more intermediate topics, with a follow-on 4-day course on advanced topics. But really, by the time you get to the advanced course you'll learn a lot by just reading some good books on the topic. (And no, "Teach Yourself OO in 24 Hours" doesn't qualify as a "good book". ;))
I downloaded the JavaFX SDK for this reason... and yeah I get the bit about not simply splicing in code, especially in OO vs Procedural... but even example code for visuals is better than just pictures.
Oh, I definitely agree. It helps to play around with interactive applications.

For JavaFX you'll likely want the JFXtras library as well since it adds support for some things that Sun has not (yet?) added to JavaFX. (This likely won't apply to you, but things like JTable and JTree don't exist in JavaFX so they have to be imported from Swing with wrappers around them.)

Chrest
Cave Troll
Posts: 46
Joined: Mon Mar 16, 2009 4:56 pm

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by Chrest »

I just found this topic, and I haven't read through all 20 pages of it, so if I'm duplicating previous comments, I apologize. I'll try and keep my suggestions brief in case someone has written them before.

1) Mimic Google/Yahoo/Bing maps as much as possible, so that new users don't have to re-learn a new interface. Dragging the map should be left-click, not right-click, and display a hand icon. A mini-map like in RTSes would also be helpful.

2) Common token-editing functions should be made available via an on-map interface that fades in around the token when there is a mouseover. This might include editing commonly changed attributes, rolling dice, and accessing an editing screen where less-commonly changed attributes can be modified (e.g. light sources).

3) Commonly used bookkeeping tasks should be able to be accomplished (quickly!) via the UI in 2). For instance, players should be able to set up common dice rolling macros (such as opposed checks) without typing code. Many of the players in my group still use spreadsheets for tracking HP, etc., because they don't want to bother to learn the macro programming language. A quickly accessible interface (maybe near the token, or maybe a tabbed pane including an editable stat sheet) to allow this kind of bookkeeping, linked to a basic visual macro creation interface, would be enormously helpful. The macro system would still be underneath for power users.

I suggest playing through a few sessions of some common gaming systems with advanced players, and noting down which macros they use most frequently. Then make these functions quickly accessible via GUI.

4) Create different viewing modes for players, GMs acting as players (i.e. during combat), and GMs acting as the world (i.e. during exploration of a dungeon). The focus for the player mode and the GM-as-player mode should be on tokens. Token stats, states, macros, and positions should make up the majority of the interface, while drawing tools should be hidden. On the GM-as-world screen, drawing tools and token creation and deletion should be more prominent. This will make the interface more accessible for new users by removing elements that are not important for the current usage mode. The different modes should be easily accessible via tabs or buttons so that the existence of viewing modes is visually apparent.

Two specific gripes:
1) The interface for selecting transparent colors needs fixing. Currently, you have to press Cancel, which violates both the expected behavior of a color palette, and the expected behavior of a Cancel button.

2) The change-maps button is really confusing; it looks like a status icon rather than a clickable button. My GM creates enormous maps, so my group only changes maps once every few weeks, and when we first started using MapTool, someone would forget where the button was practically every time we switched to a new map, because it's really tough to find. It's in an out-of-the-way corner of the window, there's no bezel or other indication that it can be clicked, and it looks kind of like the old IE spinning-world page-loading icon. Your eye just slides right over it.

Hopefully these are helpful!

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by jfrazierjr »

Chrest wrote:I just found this topic, and I haven't read through all 20 pages of it, so if I'm duplicating previous comments, I apologize. I'll try and keep my suggestions brief in case someone has written them before.

1) Mimic Google/Yahoo/Bing maps as much as possible, so that new users don't have to re-learn a new interface. Dragging the map should be left-click, not right-click, and display a hand icon. A mini-map like in RTSes would also be helpful.
I am not saying this won't be done, BUT, now you have thousands of existing players who have to relearn how to work with Maptool.
Chrest wrote:2) Common token-editing functions should be made available via an on-map interface that fades in around the token when there is a mouseover. This might include editing commonly changed attributes, rolling dice, and accessing an editing screen where less-commonly changed attributes can be modified (e.g. light sources).
Not quite sure what you mean here.
Chrest wrote:3) Commonly used bookkeeping tasks should be able to be accomplished (quickly!) via the UI in 2).

For instance, players should be able to set up common dice rolling macros (such as opposed checks) without typing code.
They can do that now. Impersonate token,right click on the Impersonated macro panel and click new macro. Right click the new macro and click Edit(yea, this step is a PITA as it should just open a new macro edit window). Type in the roll expression within brackets or braces(eg, "{3d6}").. Done... This should take a player about 20 seconds and once set up, they just click the button...
Chrest wrote:Many of the players in my group still use spreadsheets for tracking HP, etc., because they don't want to bother to learn the macro programming language. A quickly accessible interface (maybe near the token, or maybe a tabbed pane including an editable stat sheet) to allow this kind of bookkeeping, linked to a basic visual macro creation interface, would be enormously helpful. The macro system would still be underneath for power users.
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.

Chrest wrote:4) Create different viewing modes for players, GMs acting as players (i.e. during combat), and GMs acting as the world (i.e. during exploration of a dungeon). The focus for the player mode and the GM-as-player mode should be on tokens. Token stats, states, macros, and positions should make up the majority of the interface, while drawing tools should be hidden. On the GM-as-world screen, drawing tools and token creation and deletion should be more prominent. This will make the interface more accessible for new users by removing elements that are not important for the current usage mode. The different modes should be easily accessible via tabs or buttons so that the existence of viewing modes is visually apparent.
Hmm... I don't know if this would make it into 1.4, but I can see some use for this. There are talks about making more things "context sensitive", and this would fall under that category.
Chrest wrote: Two specific gripes:
1) The interface for selecting transparent colors needs fixing. Currently, you have to press Cancel, which violates both the expected behavior of a color palette, and the expected behavior of a Cancel button.
While I am not 100% sure, I "believe" this is an issue with using the default java color picker(which does not have any way to set transparency on said dialog window). Rewriting that section is a fairly large undertaking, so I kind of doubt it will happen unless someone on the internet has already done up such a model and has a license which would allow us to plug it into Maptool. I agree, it can be annoying though....

Chrest wrote: 2) The change-maps button is really confusing; it looks like a status icon rather than a clickable button. My GM creates enormous maps, so my group only changes maps once every few weeks, and when we first started using MapTool, someone would forget where the button was practically every time we switched to a new map, because it's really tough to find. It's in an out-of-the-way corner of the window, there's no bezel or other indication that it can be clicked, and it looks kind of like the old IE spinning-world page-loading icon. Your eye just slides right over it.
Agreed....though.. I am not quite sure what the best way to fix it would be. Perhaps move it over to the toolbar as it really is a tool just like the FOW, VBL, etc tools are in concept. Shrug...
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

User avatar
JonathanTheBlack
Dragon
Posts: 544
Joined: Mon Jun 28, 2010 12:12 pm
Location: I'm the worm...

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by JonathanTheBlack »

Chrest wrote:1) Mimic Google/Yahoo/Bing maps as much as possible, so that new users don't have to re-learn a new interface. Dragging the map should be left-click, not right-click, and display a hand icon. A mini-map like in RTSes would also be helpful.
This would be awesome.
4) Create different viewing modes for players, GMs acting as players (i.e. during combat), and GMs acting as the world (i.e. during exploration of a dungeon). The focus for the player mode and the GM-as-player mode should be on tokens. Token stats, states, macros, and positions should make up the majority of the interface, while drawing tools should be hidden. On the GM-as-world screen, drawing tools and token creation and deletion should be more prominent. This will make the interface more accessible for new users by removing elements that are not important for the current usage mode. The different modes should be easily accessible via tabs or buttons so that the existence of viewing modes is visually apparent.
This can be done somewhat by dragging windows around and placing them on top of each other into tabbed setups. For example, when I'm working on scripting and running a game, I have the Impersonated, Selection, and Campaign panels visible, with Library and Map Explorer in tabs behind Impersonated and Select. When I'm mapping and preparing a dungeon, I bring the Library and Map Explorer forward and then close Campaign and Chat to give me room to work. It's easy enough to switch that I can work that way during a game while players RP.
Spoiler
Image
2) The change-maps button is really confusing; it looks like a status icon rather than a clickable button. My GM creates enormous maps, so my group only changes maps once every few weeks, and when we first started using MapTool, someone would forget where the button was practically every time we switched to a new map, because it's really tough to find. It's in an out-of-the-way corner of the window, there's no bezel or other indication that it can be clicked, and it looks kind of like the old IE spinning-world page-loading icon. Your eye just slides right over it.
I agree 100%! I have had to explain how to switch maps so often, that I just use enforce players to map rather than try to explain it.

Phergus
Deity
Posts: 7132
Joined: Fri May 12, 2006 8:56 pm
Location: Middle of Nowhere, NM
Contact:

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by Phergus »

Chrest wrote:1) Mimic Google/Yahoo/Bing maps as much as possible, so that new users don't have to re-learn a new interface. Dragging the map should be left-click, not right-click, and display a hand icon. A mini-map like in RTSes would also be helpful.
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.

The mini-map was removed quite some time ago and there didn't seem to be that many users who cared. Maybe it could be revisited and/or made optional.
Chrest wrote:2) Common token-editing functions should be made available via an on-map interface that fades in around the token when there is a mouseover.
The problem will be that it will always pop up too quickly when you don't want it and not quickly enough when you do. Would drive the GM crazy.
Chrest wrote:4) Create different viewing modes for players, GMs acting as players (i.e. during combat), and GMs acting as the world (i.e. during exploration of a dungeon).
This idea was floated quite some time ago by Trevor when he first started talking about redoing the gui. Have the gui change to match the mode of use (player, GM , world creation) on startup depending on the choice made by the user.
Chrest wrote:1) The interface for selecting transparent colors needs fixing. Currently, you have to press Cancel, which violates both the expected behavior of a color palette, and the expected behavior of a Cancel button.
Perhaps you could use it the right way. If you want to turn off either the Foreground or Background fill colors you can just left- or right-click in the first color box with the red slash through it.
Chrest wrote:2) The change-maps button is really confusing; it looks like a status icon rather than a clickable button.
This mostly just takes away what little hope for humanity that I still had.

Is it immediately obvious? Not so much though it is a globe symbol. When you hover over it you get a tooltip and like the other tools on the toolbar it shows the outline, indicating clickable, while hovering.

Perhaps it could be changed to a regular text button that says "Change Map". There was discussion about adding an option to the Map menu to call up a dialog for selecting the active map but I guess it didn't go anywhere.

User avatar
Azhrei
Site Admin
Posts: 12086
Joined: Mon Jun 12, 2006 1:20 pm
Location: Tampa, FL

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by Azhrei »

Phergus wrote:
Chrest wrote:2) Common token-editing functions should be made available via an on-map interface that fades in around the token when there is a mouseover.
The problem will be that it will always pop up too quickly when you don't want it and not quickly enough when you do. Would drive the GM crazy.
I'm sure we'll be playing with something like this eventually. Whether it will remain or not will be up to the community. We'll try to implement something like this and we'll release a build and the users can tell us if they like it not. That's how things work around here. Usually. ;)
This idea was floated quite some time ago by Trevor when he first started talking about redoing the gui. Have the gui change to match the mode of use (player, GM , world creation) on startup depending on the choice made by the user.
And this is still the plan, although it won't be limited to "startup". I'm thinking that the different modes (for lack of a better term) will be listed in a dropdown box on the toolbar. Selecting a mode causes the UI to restructure itself with different options. Once a mode is selected changes to the screen layout (where pieces appear, for example) would be specific to the mode and would be saved so they'll reappear in the same spot next time that mode is selected.

I give the above only a small chance of being implemented in the early builds of 1.4 though. Just not a super high priority.
Perhaps you could use it the right way. If you want to turn off either the Foreground or Background fill colors you can just left- or right-click in the first color box with the red slash through it.
This could be done much better than it is now. Even if there's just a dedicated field called "Empty" or "Transparent" or "None". At a minimum we should have tooltips over each box that give the color name/number and the red slash box could be named "None". There are no instructions on what it means to right-click or left-click either. :(
Perhaps it could be changed to a regular text button that says "Change Map". There was discussion about adding an option to the Map menu to call up a dialog for selecting the active map but I guess it didn't go anywhere.
We have top men working on it. "Top men."

:mrgreen:

I believe the idea (for MT 1.3) is to popup a scrolling listbox and double-clicking an item in the list opens that map. The listbox will be accessible from the Map menu but probably also a button such as the globe or something else.

User avatar
JonathanTheBlack
Dragon
Posts: 544
Joined: Mon Jun 28, 2010 12:12 pm
Location: I'm the worm...

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by JonathanTheBlack »

I'd like better support for multiple monitors. If I forget to move a window back from my second monitor before I close MapTool, when I open it again, the windows I drug into the second monitor come up as black squares.

Chrest
Cave Troll
Posts: 46
Joined: Mon Mar 16, 2009 4:56 pm

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by Chrest »

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.

bstrdsmkr
Cave Troll
Posts: 41
Joined: Sat Jun 05, 2010 8:58 pm

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by bstrdsmkr »

Chrest wrote: 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.
Just don't forget about us touch screen users ;)

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by jfrazierjr »

Chrest wrote:
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.
Ok.. This makes sense now. But at least currently, why not make use of the Notes section of the token? Also note that things such as "turn undead for 6 rounds" should probably be an Initiative tool event(which is not directly supported now, though there are tons of ways to "hack" it into place if you so wish) without huge effort.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

Chrest
Cave Troll
Posts: 46
Joined: Mon Mar 16, 2009 4:56 pm

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by Chrest »

jfrazierjr wrote:Ok.. This makes sense now. But at least currently, why not make use of the Notes section of the token? Also note that things such as "turn undead for 6 rounds" should probably be an Initiative tool event(which is not directly supported now, though there are tons of ways to "hack" it into place if you so wish) without huge effort.
Primarily inconvenience--there are two clicks and a long menu required to get to the Notes section, and once I'm there I'm in a modal window that blocks me from doing anything else until I finish editing the token. I usually find it easier just to have a text document or piece of paper handy, because I have to do it all again to look at my notes.

Agreed on the initiative tool; that's the preferred way of accomplishing this. Although, even with init events, putting the attribute in question on a token is a valid way of creating the event--there are plenty of rules systems that require modifying token attributes on a recurring basis (e.g. regeneration and poison-type effects). So you could treat turn undead as a global event that has a set duration, or as a token attribute on the Undead (or the Cleric) that is decremented once each round.

User avatar
jfrazierjr
Deity
Posts: 5176
Joined: Tue Sep 11, 2007 7:31 pm

Re: Maptool Concepts: The Next UI, Look, and Feel

Post by jfrazierjr »

Chrest wrote:
jfrazierjr wrote:Ok.. This makes sense now. But at least currently, why not make use of the Notes section of the token? Also note that things such as "turn undead for 6 rounds" should probably be an Initiative tool event(which is not directly supported now, though there are tons of ways to "hack" it into place if you so wish) without huge effort.
Primarily inconvenience--there are two clicks and a long menu required to get to the Notes section, and once I'm there I'm in a modal window that blocks me from doing anything else until I finish editing the token. I usually find it easier just to have a text document or piece of paper handy, because I have to do it all again to look at my notes.
I guess my point is that I can't really envision a way to make some generic thingy that holds arbitrary text and makes it available to the UI to be changed any quicker than it does now. Perhaps something like "add note" to the right click menu which pops up a smallish text box dialog window? And then say, have a dockable frame named "Token X Notes" that sort of functions in the way that many task list tools work?

I will say that I doubt that we will allow arbitrary properties on a token for a user to just create them selves to store just anything in that they want.
I save all my Campaign Files to DropBox. Not only can I access a campaign file from pretty much any OS that will run Maptool(Win,OSX, linux), but each file is versioned, so if something goes crazy wild, I can always roll back to a previous version of the same file.

Get your Dropbox 2GB via my referral link, and as a bonus, I get an extra 250 MB of space. Even if you don't don't use my link, I still enthusiastically recommend Dropbox..

Post Reply

Return to “Developer Notes”