Maptool Concepts: The Next UI, Look, and Feel

[jfrazierjr]

If it actually did stuff, it would be even more fun!

Hmmm.. then make it do stuff!!! Perhaps tie a move icon as posted earlier and tie that to the existing move menuitem. That should be fairly easy to tie together I would think if you already have the menu itself poping up. I would be happy to give it a quick test if you want to send me a patch and let me know where to get the library.

[Rumble]

If it actually did stuff, it would be even more fun!

Hmmm.. then make it do stuff!!! Perhaps tie a move icon as posted earlier and tie that to the existing move menuitem. That should be fairly easy to tie together I would think if you already have the menu itself poping up. I would be happy to give it a quick test if you want to send me a patch and let me know where to get the library.

Oh, man, but that's hard.

Actually, the real issue was that I was so busy making it look right (the radial menu thing is pretty clever, but it's somewhat limited in what it looks like, and I spent like, 2 hours just tweaking the code to make it attractive) that I didn't actually make it do anything. Given that it's a modification of some J-component things, I should be able to add actions from the existing right-click menu pretty seamlessly*









* famous last words.

[n3phrit]

I think that discussion is stucked on "radial menus", which is IMO secondary problem. How final elements will look like should be solved after initial discussion about the question: What is MT approach to UI as a whole?
1. Is it fully customized, so every single elements can be scripted for given purpose?
2. Is it predefined elements that are tight to certain behaviours?

secondary we should discuss what technology should be used for UI elements/styling.
Again I am going to think "out of the box".

We were discussing javascript integration (didn't see any details about this through)
but I rembember that Azhrei mentioned in 1.4 features thread HTML/CSS support.
Now, if MT supports HTML, Javascript, CSS (at least 2.1) and javascript is utilized smart and fast way, we have already everything we need. All GUI can be then constructed by HTML/CSS/JS combination the same way as current webpages are (including roundabout/circular menus, transparency). In this reality, we already have what we want, just imagine, you can program interface just like any other web page interface with js (e.g. jquery). I have concerns about performance of such engine, but it is quite possible that it would perform well anyway!

[Rumble]

Quite right - radial menus are a sideline. Sorry to drag it off track!

As to the HTML/CSS/JS approach, I'm of two minds. On the one hand, it's really cool. On the other hand, unless UI customizability can be done without knowing HTML/CSS/JS, I think a lot of users could be left out in the cold.

Obviously, you need to learn the macro language to get the most out of it, but you also have to learn a whole lot about it to get even a little out of it, really. I wouldn't want the GUI to go that route - a fully customizable "I can do anything with it" engine is very cool, but for people (like me, who to be honest doesn't really want to learn how to write a UI in javascript), I'd like it to be mostly customizable via other means.

In other words, if I want Absolute Power over the UI, then I must make the effort to learn the way its written. But if I want Reasonably Adequate But Not Too Much Because That Would Be Tacky Power over it, I don't want to have to learn the language trio to get there.

So it's worth thinking about, but I'd hate for it to turn into "MapToolKit", where you can build your own VTT if you learn how to write scripts and design HTML/CSS interfaces.

[n3phrit]

So it's worth thinking about, but I'd hate for it to turn into "MapToolKit", where you can build your own VTT if you learn how to write scripts and design HTML/CSS interfaces.

Why is that? If MT comes default with everything you need, lets say predefined elements, you can still customize them without knowing much about how they work.
Underneath there will be world for heavy scriptors/modders who can prepare whole new elements for the community to use. The same way, you can use different macro frameworks that are currently developed by different users...

[dorpond]

Tablet computers aren't taking the world by storm, but they might pick up steam, and pen/stylus/touch compatibility is a good idea to think about (imo, at least).

I agree with this 100%

I have a Google Android device and I am floored by how easy it is to navigate and use. I also have a I-touch and I have the same opinion. Both devices have applications that are easy to use and navigate.

I think the next generation of users are going to be very comfortable with the way these devices work and how to navigate them. I think if we had similar ways of navigating Maptool, it would not only be attractive to new users, it would be comfortable to them.

Here is a quick mockup for example. The mockup was made by Torstan and I modified it a bit to have that 'flick/click left or right to switch between panels' feel to it. Imagine flipping through your maps in this manner.

Overview Modified 1.jpg (183.88 KiB) Viewed 1182 times

Nonetheless, like you said Rumble, it supports mouse and touch which to me is ideal.

[dorpond]

Rumble, I just now saw that mockup of yours on Page 4 (that's what I get for using my phone to keep in touch ). I am glad you put that together - thanks! It really gets the wheels spinning.

- I was looking at the mini-map image and I really like the dot representation of friend/foe. I then thought about how Unbound maps would need to work -that was our biggest issue with the mini-map in earlier versions of Maptool (which is why we ended up taking it out), but as I was looking at the mini-map in your mockup, I suppose the easiest thing to do is to allow a user to zoom in and out in the mini-map. Perhaps with the wheel (mouse), Zoom in/out buttons on mini-map (mouse), or perhaps even multi-touch (touch).

- I was looking at the footsteps ont he radial dial and that reminded me how we need to have the ability to pick up units and place them into position on the map - sort of like checkers. We have had many discussions about this in the past in previous threads but that could allow for some very interesting animated movements and such. Plus it would prevent auto FOW exposure to take place when someone needs to just place their token somewhere else on the map. Anyway, those footsteps reminded me of the need to support that. See? Mockups are good.

[Rumble]

Why is that? If MT comes default with everything you need, lets say predefined elements, you can still customize them without knowing much about how they work.

One point - that is not a given. Your assumption is that "MT comes default with everything you need," to which I say that is something that has to be consciously written into the program.

One of MapTool's problems (earlier on at least) was that it was seen as a "VTT for people with computer science degrees." People on this forum felt that way, even. Now, that's softened a bit (or I hear it less, or ignore it more ).

If the tool - no matter what the underlying technology - is designed and implemented so that I can customize it to a fair extent without having to know anything about the underlying tech, that is excellent and should be (IMO) the goal. If it is not implemented to be easily customized, then we may exclude people who might want some changes, but not want to learn a whole new world of coding to do them.

But it comes down to the fact that it will only come with everything you need and all the predefined elements if it's written that way. That's what I meant by "MapToolKit" - I don't want a pile of GUI widgets; I want a custom interface that I can play with by drag, drop, click, and maybe "add icon set."

So, maybe another way of putting it: I don't think you're wrong, or anything. I think it would work quite well assuming peformance is excellent. What I would like is no matter how it's implemented, to make sure it is implemented so that, 80% of the interface customization can be done without a line of code using predefined stuff and your own provided images, and the remaining 20% of the custom work is the really incredible "How did you DO THAT AWESOME THING???" that requires you to get your hands dirty with the code.

(note: 80/20 are random numbers, it could be 77/23 for all I care )

[Jector]

One of MapTool's problems (earlier on at least) was that it was seen as a "VTT for people with computer science degrees." People on this forum felt that way, even. Now, that's softened a bit (or I hear it less, or ignore it more ).

I never really thought that. To get the full benefit out of it you needed to have coding skills, but as a battlemat it worked just fine. Better, in fact, than a lot of paid VTTs. I think too many people saw the macros and went "Ewww! This program is too hard!"

MTs greatest strength is that it isn't designed for one game system. This is also it's greatest weakness as this means you can't just set up everything just so to work perfectly for that one system. So you have to leave it open for any system, some of which are pretty darn wacky. It would be nice to be able to have little pop-up menus to customize everything to your needs but the sheer diversity of rules out there would certainly leave some system out in the cold.

Mind you, I'm still of the opinion that we should make lots of things easier to adapt by computer noobs but still leave the option for deeper customization by others who have the ability to dig into the language.

[venger]

I have some issues with that setup - the biggest two are first, I wouldn't want to have the resource library tied to a particular layer. I use and reuse images in many ways, and I would not want to have to first copy a particular image into another library before I can place it on a particular layer - I think the "change to layer" functions are adequate (though I am deeply interested in a new layer system!).
Of course, they should be there for the folks that do use 'em, but they shouldn't be the assumed interaction method. The approach you're taking, venger, is very heavily keyboard-focused (every function is keystroke related) and I'm not sure that's a good direction.

I agree the Layers system could be a little more flexible. But it is adequate. I use it extensively.
Could have a single resource library of images, and reference the same image but assign to different layers but as you say, thats not a huge benefit.

I wasn't specific in my post, but an icon driven system should have been assumed, so keystrokes driven system would be a welcome addition to those of us who come from CAD backgrounds.

Switching layers with a keystroke would allow faster interface manipulation and one could map as quickly as their ideas form up.
It takes a brief moment to switch layers via mouse pointer by moving it up to an Icon and clicking it.
But this gets repeated hundreds of times in the course of a large mapping project. Keystrokes are simply faster (for me) is what I was trying to say.
All major apps have huge keystroke command sets because the pro users rely on them for the speed they afford them.

Unless there is a way to use keystrokes to change layers is already supported and I don't know about it yet? Please advise.

I liked the stamp tool idea with the wheel programmed to select because stamping object after object would be a very fast way to lay down lets say a wooded trail with lots of trees and roads segments and then 30 orc tokens or lets say dungeon geomorphs whos edges match, you could lay down a huge dungeon or wood section in minutes.

If you get a chance observe Campaign Cartographer and how it allows you to place map objects and that method is great for someone with little time and huge imaginations!

Maptool as is.. you have to repeatedly select the resource in the library and add/drag it to the map.
Or do as I do it, I used CNTR-C to copy an image already placed and then CNTRL-V and point to wherever I want them on the map, but this method does not allow for accurate placing in the case of dungeon geomorphs and I have to spend time arranging the object... time I would rather be dropping more objects accurately into place as fast as I could cntrl-roll my wheel and click

Non-keystroke users would still have the option of using a menu to select their image

I just feel like something like a stamp tool would be a huge leap for maptool mapping efficiency.

Anyway, thanks for listening.
I do not wish to seem argumentative with my reply.

I have been die hard maptool user since ver 1.b.32 or something like that, I have given generous donations to this project I feel is a worthy one, and I am a hard core maptool fan and passionate about it and I look forward to the latest and greatest whatever it may be.

Keep up the great work.

[Jector]

I liked the stamp tool idea with the wheel programmed to select because stamping object after object would be a very fast way to lay down lets say a wooded trail with lots of trees and roads segments and then 30 orc tokens or lets say dungeon geomorphs whos edges match, you could lay down a huge dungeon or wood section in minutes.

This is easy to do with "snap to grid" on and properly sized images. They fit in place fine so long as you have the right images. And if the wheel scrolled through images what would you use to rotate them? I'd think a key for cycling through images would be better, personally.

On the "look" front:
This is a little closer to what I had in mind. The rings would have to be a lot crisper and I'm toying with just making them cogs instead of doing a separate steampunk version.

[Shpena]

Coming from a campaign cartographer background, I agree it is a great way to quickly hash out stuff. Another thing CC has is the random image selector for stamping out stuff. Instead of stamping out the same tree, it randomly chooses from a list of predetermined images.

If maptools could have something like that random image stamping so the forest won't look so boring, it would be cool. Something like either the random image thing or have the user select images into a short queue and use that as the randomized images.

I also agree with the maptoolkit idea. A one size fits all approach is impossible because people have different tastes/needs, so having a customized ui would totally be awesome. GM doing it and allowing the users some minor customization

Man, I'm getting excited reading through this thread. If I only could program I'd be coding till my fingers bled

[Rumble]

I also agree with the maptoolkit idea. A one size fits all approach is impossible because people have different tastes/needs, so having a customized ui would totally be awesome. GM doing it and allowing the users some minor customization

I on the other hand disagree with this approach, unless (like I said) ~80% of that customization is doable without any coding (I also think that the customization should be fully available to the user and the GM; if the user wants to make his interface scream in ways the GM doesn't know how to, he or she should be free to do so).

Again, if MT hypothetically did an HTML/CSS/JS interface, and said, "Here is the default interface. Extensive options to customize the look and feel are available in the Preferences > Theme menu. If you want to write your own themes, look at Writing Themes for MapTool. You should be experienced with HTML, CSS, and Javascript." I would think that was intimidating, but acceptable - I can do most of what I want without knowing how it works, and if I want more, I'll have to learn.

On the other hand, if MT presented the interface as customizable, and then offered very limited customization without writing your own theme or knowing how to edit someone else's, that would be intimidating, but not acceptable to me.

Right now, we don't get to customize the UI (and it's not presented as such), so we live with what we get. But, it is my opinion that, if MT is going to have (some day) a customizable UI, then please, please make it really easy to customize without coding.


Incidentally, I also think simple macros should be buildable without coding, but that's a separate topic.

[dorpond]

My general view is this; I want Maptool to be easy to figure out for the first time user. I want them to sit down and within minutes, be able to figure out what to do so that gaming can commence with little learning curve.

While I like the theory of being able to customize everything, I am afraid that the end result will be users sitting behind all sorts of modified Maptools and suddenly the learning curve goes up.

I think once we get an interface that we all feel good with, we should stick with it. Skin it to death if you want but keep the core the same, this way all users can sit in and know how to navigate it. This way one shot games won't suffer and any user can fill in with little disruption.

Imagine if I changed the look and feel of Microsoft Office on all the computers at work and told the users to figure it out. Then a week later, switch them all again - there would be an uproar amongst the users complaining that they cannot find this and that anymore - it would create a ton more work for my IT department and it would slow down production. I am not sure if that is a good idea with a VT for the same reasons.

But that is just my opinion which has just as much weight as everyone else.

[CyrusStonecypher]

Imagine if I changed the look and feel of Microsoft Office on all the computers at work and told the users to figure it out. Then a week later, switch them all again - there would be an uproar amongst the users complaining that they cannot find this and that anymore - it would create a ton more work for my IT department and it would slow down production. I am not sure if that is a good idea with a VT for the same reasons.

Yargh! The switch from Office 2003 to 2007 turned my users into rabid pitbulls. I would get mauled if the UI had another drastic change. I smell what your cookin' and see what you're sayin'!