Maptool Concepts: The Next UI, Look, and Feel

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

Moderators: dorpond, trevor, Azhrei

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: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?
How about a "Token Inspector" pane that copies the functionality of the current edit window, and applies to the currently selected token?
jfrazierjr wrote: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.
Why not? I imagine it would require a fair amount of work to code, since my bet is that the current code is pretty heavily reliant on having token properties be globally-defined. Is there any reason besides that? If it's just a matter of work, I'll probably have some time to look into it myself in the next few months, but I want to know if there are other objections.

User avatar
RPTroll
TheBard
Posts: 3159
Joined: Tue Mar 21, 2006 7:26 pm
Location: Austin, Tx
Contact:

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

Post by RPTroll »

Sorry to jump back a bit in the thread...

Concerning left-click drag vs. right-click drag: I use a number of programs that allow you to drag the screen around and Maptool is the oddball out. I'm one of the elder users of the tool and I wouldn't mind a left-right click switch. Sadly, I never mistake the click in Maptool. I only make the mistake in the other programs I use.

Now if we could just reverse the direction of token spin with the mouse wheel... :twisted:
ImageImage ImageImageImageImage
Support RPTools by shopping
Image
Image

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: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?
How about a "Token Inspector" pane that copies the functionality of the current edit window, and applies to the currently selected token?
Well, anythings possible, but I expect the way we might end up going is similar to how many of the existing frameworks go and allow users to create "templates" which will load in a frame that will act more as a character sheet. Not sure how to make it easily editable though.


Chrest wrote:
jfrazierjr wrote: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.
Why not? I imagine it would require a fair amount of work to code, since my bet is that the current code is pretty heavily reliant on having token properties be globally-defined. Is there any reason besides that? If it's just a matter of work, I'll probably have some time to look into it myself in the next few months, but I want to know if there are other objections.
Yes, code wise, it's quite tangled up. Another issue is that currently each "token" is an individual object on a single map. So, if your GM for example, set up your token on 3 maps, then you have 3 tokens and thus would have to remember to modify the "notes" storage for all of those tokens. In 1.4 we plan to make a token a SINGLE object in the entire campaign and just have each map have a pointer plus any specific things that define it's "view" on that map such as location and a few other things.

Also, you "can" have per token "private" properties now, you just have to use the correct macro call AND can only access the value via a macro since the Campaign properties are defined by the GM and it won't show up. Note that quite a few people use the "feature" today for various purposes, mostly as temporary storage locations.
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..

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 »

jfrazierjr wrote:In 1.4 we plan to make a token a SINGLE object in the entire campaign and just have each map have a pointer plus any specific things that define it's "view" on that map such as location and a few other things.
While the subject is open, I'd like to voice my preference on this. What I'd like to see is tokens saved as resources. I know they already are, but sort of like the NWN editor if anyone knows what I'm talking about. You have a set of cookie cutter tokens, a set of edited tokens, and a set of unique tokens. For example, you have "Human Male," then you have "Red Wizard of Thay," then you have "John The Slayer." It's a template system so if I go back and edit Human Male to have 3 more hp/level, John The Slayer gains 12hp. Then I place a John The Slayer on map A and map B. We play through a few encounters on map A and John The Slayer gains 3 levels. When I load map B, John The Slayer appears wherever I've placed him, but with all of the token properties, equipment and etc intact.

For what it's worth, I'd like to see the same thing for weapons and etc. The reason for this is then you can assign "containers" to players/tokens, and objects to containers. For example: I expand the plus sign next to John The Slayer's entry. Now I see he has several containers: LeftHand, RightHand, Necklace, Backpack, Belt, and however many others. In his RightHand container I see his .50 caliber Desert Eagle engraved with holy symbols. In his LeftHand container, I see his pack of bubble gum. I'd also like to be able to move containers from one token to another or drop them on the ground as an object.

After thinking about it, maybe hp/level is a bit system specific, but maybe if could be done with macros? I'm not sure about how token updating is currently done, but this might increase the amount of bandwidth used with the need to keep each connected client updated with each change on every token, but i'm sure than can be stream lined.

And now that I've chewed up a few paragraphs, I'd like to introduce another Idea for discussion that's quasi related. I'd like to have a token viewer for my Android based Nexus One. Since it seems destined for more and more devices, this would make a great screen real estate saver if all of my players could see their character sheets and equipment on their phones when we play in person. And ya'know, maybe those OTHER mobile OS's if they're lucky :lol: Taking that a step further would be things like Plo's spell library to lookup in game info on your phone. Discuss! :D

User avatar
Jector
Great Wyrm
Posts: 1164
Joined: Sun Aug 27, 2006 9:19 pm
Location: Atlanta

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

Post by Jector »

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.
From my perspective this would not be optimal. While MT is used in game as a map, it's not just a map. It's a drawing, token, and stat tracking program. While panning the map is important it is very unlikely that anything above a small minority will use that function more than drawing, painting textures, placing objects and tokens, drawing VBL, moving tokens, etc. Since the left button is always set up as the most used function for a program, than it should not be set for moving the map. Maybe as a space/left click or something, but not as just a left click.
I cast firecube! ~4E

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 »

bstrdsmkr wrote:It's a template system so if I go back and edit Human Male to have 3 more hp/level, John The Slayer gains 12hp.
And what happens when you delete Human Male?

I suppose it's possible that properties could be defined as an "aggregate" so that the property called "HP" for John The Slayer would include his value, plus any super class object's value, and so on up the tree.

I'm somewhat concerned about teaching this design to a newcomer and ensuring they know the ins and outs of it. I can see our current technique of "copy-the-token-and-change-it" being universally understandable...

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: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.
They don't actually because you are suggesting that actions be made more complex not less. Adding additional mouse-clicks or additional hands to do what is now done with less. As for laptop users, anyone dumb enough to use a program like MapTool (or Photoshop or Autocad or Illustrator...) without a real mouse deserves every bit of pain and suffering they get.
Chrest wrote:I don't think there's any question that MapTool should cater to new users.
Really? I question it. It's clear that we are well over the hump in the adoption curve and new users are going to be those less knowledgeable, less likely to participate in the community and require more hand-holding and help. This isn't a commercial product where the goal is profit. There is nothing to suggest that catering to the lowest common denominator is going to provide a benefit to anyone.

Your main point is that making MT work like all the programs that potential new users are presumed to be familiar with make the transition easier. The reality is that MT isn't functionally anything like the normal programs they are familiar with. The majority of these new users have little experience with anything beyond the basic Microsoft Office suite and Outlook (or their equivalent on MacOS or Linux). And even then they are largely inept with those tools that they do work with every day. Of course they struggle with MT. They struggle reading their email.

But having said all that I'm not against making MT more efficient to use which is not the same thing as making it easier. Adopting interface styles from other programs does make sense when the functionality there and within MT are closely aligned. It is important however to always keep in mind the focus of MT and not just copy based on surface similarities.

MT has plenty of warts in the current interface and absolutely needs to be refreshed with an eye to efficiency and ease-of-use both.

User avatar
thecyberwolfe
Dragon
Posts: 312
Joined: Thu Jun 26, 2008 3:57 pm
Location: The Great Wet North

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

Post by thecyberwolfe »

One more thing to note in the argument about dumbing-down the program: the serious users are also the GMs, a profession that requires quite a bit of intelligence, research and problem-solving. They can handle a complex program.

The users that will have the most trouble with it are the ones Phergus was talking about - and they will also be non-GMs for the most part... but they will have a GM handy that can explain to them the few simple things they will need to know to use the program in a game session.

In the end, if it is decided that things must be simplified for new users, then let's do it in a way that leaves the advanced features intact - just behind another layer of menus or maybe as a "Basic vs. Advanced" menu switcher. (But not as a GM Client vs. Player client, one codebase is sufficient, thankyouverymuch.)
The Cyberwolfe
----------------
Them: "Name one thing a PC can do that a Mac can't!"
Me: "Right-click."

User avatar
Slayve2DnD
Dragon
Posts: 455
Joined: Thu Dec 18, 2008 1:06 am

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

Post by Slayve2DnD »

thecyberwolfe wrote:One more thing to note in the argument about dumbing-down the program: the serious users are also the GMs, a profession that requires quite a bit of intelligence, research and problem-solving. They can handle a complex program.

The users that will have the most trouble with it are the ones Phergus was talking about - and they will also be non-GMs for the most part... but they will have a GM handy that can explain to them the few simple things they will need to know to use the program in a game session.

In the end, if it is decided that things must be simplified for new users, then let's do it in a way that leaves the advanced features intact - just behind another layer of menus or maybe as a "Basic vs. Advanced" menu switcher. (But not as a GM Client vs. Player client, one codebase is sufficient, thankyouverymuch.)
I think your idea of a menu switch is "easy". HOWEVER, a GM vs PLAYER client would allow for the GM client to do more powerful and complex things without worrying about too many bugs in a switch trigger code change. Granted its two (partially) different codes, but a GM's tools need to be powerful enough to stop a player from messing something up by accident, or a players client needs to not be powerful enough to mess with any campaign stuff and only allow for macro execution and token movement. This should also make the clients lightweight (individually).
I'm not retarded...I'm a simple creature...there is a difference.

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 »

It's expected that the UI will be self-configuring so that GMs see more UI elements than players do. How extensive that becomes remains to be seen.

User avatar
RPTroll
TheBard
Posts: 3159
Joined: Tue Mar 21, 2006 7:26 pm
Location: Austin, Tx
Contact:

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

Post by RPTroll »

That would be most welcome.
ImageImage ImageImageImageImage
Support RPTools by shopping
Image
Image

Ephestion
Cave Troll
Posts: 26
Joined: Tue Feb 17, 2009 9:49 pm

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

Post by Ephestion »

A Global Macro Editor in module format.
Instead of assigning macors to a library token, they should appear in a tree diagram as modules.

Say i want to play the same map using different rules hence different macros, i should be able to click on a menu item that loads presets for D20, D&D 3.5, 4 etc, Pathfinder or whatever else is developed as a module.

All PC's should inheret the presets for PC's
All the NPC's should inheret the presets for NPC's

Global Macros:
MapTool Global Macros MODULE
MODULE ADDS THESE MENU ITEMS In MACRO MENU
- Import Saved Token/s (imports a copy or the actual token don't know which would be better)
- Export Current Token/s (saves a token then imports it into a map)
- Teleport Player/s to Map
- Set Day Night Cycle (1 day = 2hrs game time etc)

Anything that seems to be useful and generic enough to be applied to any map or game.

D&D 4E Macros
MODULE ADDS THESE MENU ITEMS IN MACRO MENU
- Create New Player (Character Builder)
- Player Character Sheet
- NPC Character Sheet/ Card
- Initiative Handler (Launches initiative tool)
- Combat Handler
- Skill Checks
or whatever else needs to be handled to save time. The complexity of the module will enable certain calls from the tokens to these libraries.

So when a Player Character sheet needs to be viewed it can be raised as a dialog box with the content defined by the Global Macro. STR, DEX, CON and all the things that appear in a 4E CS. It may be done as XML, HTML on the fly or just an extesnion of existing system. (Some time the roll over Statistics we see for a token can be anoying as they cover the token.)

When a token is imported (probably as a copy) it will be assigned all the properties needed by the Global Macro System eg D&D 4E Module. So a player may edit the stats of their token in a comfortable way since all the Character sheet information will be present in a familiar and organised way. No more need to manually copy and paste Token attributes between tokens.

This will add portability to tokens in that a player may wish to have a copy of his token so that he can play with it in other similar games. It also defines a game system. Because the current way of using Frameworks is rather sloppy and is not a pollished way for handling different game systems.

As Bug Fixes are concerned: b77-80 presented some issues when i tried to explore a map as a player with limited visibility ie Night, Torch Light SOurce. These were apparent in Vegies and Rumbles Frameworks. There should be a way to reset fog of war and that player tokens can be set to be always visible. For example when moving into an unexposed area a player loses his token in the darkness instead of revealing the area. When the token arrives it should remain visible to the player or impersinator. Also when using Tokens from these frameworks they have a setting for who controls the token and it is labeled "Player", if this is changed the option to revert back to Player is lost.

Good Luck!

Elorebaen
Dragon
Posts: 365
Joined: Sat Dec 22, 2007 5:37 pm

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

Post by Elorebaen »

thecyberwolfe wrote:One more thing to note in the argument about dumbing-down the program: the serious users are also the GMs, a profession that requires quite a bit of intelligence, research and problem-solving. They can handle a complex program.

The users that will have the most trouble with it are the ones Phergus was talking about - and they will also be non-GMs for the most part... but they will have a GM handy that can explain to them the few simple things they will need to know to use the program in a game session.

In the end, if it is decided that things must be simplified for new users, then let's do it in a way that leaves the advanced features intact - just behind another layer of menus or maybe as a "Basic vs. Advanced" menu switcher. (But not as a GM Client vs. Player client, one codebase is sufficient, thankyouverymuch.)
+1

Phlod
Kobold
Posts: 6
Joined: Wed Jul 16, 2008 12:41 am

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

Post by Phlod »

I tried searching to see if this has been suggested yet, but I didn't find much.

The *only* thing I have found lacking in MapTool so far is Back/Forward buttons on the Resource library when I'm creating maps. I have a whole lot of tokens and map tiles these days, not to mention random objects that may, or may not be adequately filed in subdirectories, and finding the same token again can be painful sometimes.

As for the rest of the UI, frankly, it's not pretty, but I couldn't care less. Once I found that I could unpin windows so they just get out of my way when I don't want them, I was happy. When I discovered I could actually drag those windows out of MapTool proper, and put them on my second monitor, out of the way, but still visible, it shot to the top of my 'favorite UI' list. Really.

IMO, great job Dev team, and thank you!

User avatar
Jshock
Dragon
Posts: 311
Joined: Sat Jan 26, 2008 8:55 pm
Location: West Warwick, RI
Contact:

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

Post by Jshock »

Phlod wrote:I tried searching to see if this has been suggested yet, but I didn't find much.

The *only* thing I have found lacking in MapTool so far is Back/Forward buttons on the Resource library when I'm creating maps. I have a whole lot of tokens and map tiles these days, not to mention random objects that may, or may not be adequately filed in subdirectories, and finding the same token again can be painful sometimes.
Why not do one better, and put search fields in a few places (map layers, resource library, etc)?

Post Reply

Return to “Developer Notes”