Zugg Software :: View topic - CMUD - Awesome base foundation ideas there Zugg!

GURU Joined: 10 Oct 2000 Posts: 873 Location: USA

Exciting. I'll bet it's going to be a busy three months for you :)

I know you can't make promises on the releases, but will we get some screenshots and preliminary specs for things like the plugin capabilities?

-Tarn

Apprentice Joined: 14 Sep 2005 Posts: 121

Yeah I'm with Tarn, but I'd prefer to have some screenshots for use in getting ideas for that logo. I don't get paid as much as I used to when I bought zMUD and the idea of free stuff from Zugg for making a badass logo, icon, splash, or banner just is too good to pass up :P

Wanderer Joined: 25 Oct 2005 Posts: 99

I am really looking forward to the restructured COM interface. That feature alone makes it worth the buy. The fact you're adding even more is just great!

Posted: Fri Dec 09, 2005 10:05 pm

I probably won't post any screen shots until the release is closer. Too much can change during development and we'll have lots of chances to change/improve stuff during the Beta period.

I could probably post a screen shot of the new Package Editor, although it's not really that impressive. Most all of the work I'm doing is "behind the scenes" and the main user interface is getting streamlined. The main MUD window isn't going to look that different than zMUD. After all, the main part of a MUD client is still the text window.

I'm planning to change the default color layout from the "green on black" to something more like "black on white" (but probably won't use pure white in the default skin). The docking captions look a bit different, and things have a better "Windows XP" look and feel, but again, it's not very exciting.

The exciting completely different DirectX-based graphical interface that we briefly talked about back in the zMUDXP Wish-list thread just wasn't possible to do what I wanted. It was just too slow. I will explore more of this in the future, but I removed that kind of complete interface overhaul from any initial release. I decided to concentrate on stuff that would be of more "practical" use to MUD players, such as packages, compiled scripts, etc, and worry less about how "cool" it looked.

Besides, the skinning should handle the "cool" part, and that will be one of the last things I work on before the first release. Right now I'm just counting on the fact that I'm using zApp controls and since zApp was themed, that should make CMUD themed. And as I mentioned in the Features thread, I expect there will be a lot of stuff that needs tweaking in the theme/skin support during the beta period (theme/skins was always one of the biggest headaches in zApp).

So, sorry I couldn't help "inspire" you more with graphics. Then again, logos and splash screen really have little to do with what the program looks like. The products that just have a screen shot on the box or in the splash screen just means they couldn't think of anything more creative, or couldn't afford a graphical artist.

We considered hiring a professional artist to do the logo, but when I saw their quote for the cost, I about died. We are way too small of a company to afford what most "professionals" charge. Thus, the contest idea ;) Fortunately, even if I don't get anything from the contest, I already have a decent idea in mind for the graphics. I will just have to spend more time with Photoshop.

Novice Joined: 16 Oct 2000 Posts: 43 Location: USA

So Zugg, how is the UI being prototyped? Any paper prototyping with some local folks? Any plans on sending some screenshots to some of your trusted testers? I'm a big believer in usability testing (having run a bunch of tests on desktop clients and dev tools in a previous life) and would love to see a revamped UI!

GURU Joined: 24 Sep 2000 Posts: 1237 Location: USA

I've got to chime in with the UI prototyping interest. I've spent the last year looking at software/website usability issues for work and have found that what makes sense to me (as a developer) can often be FAAAR from what a user expects things to look like, do, etc.

Paper prototyping is great when you've got an audience nearby who might see things differently than you do, but I think the only captive audience Zugg has is Chiara, and well, she's biased. :) FYI, paper prototyping is where you sketch the UI, and sketch each popup or other window that could open, and ask a tester to perform a task (e.g. "create a trigger"). The tester points to each button or whatever UI objects (virtually "clicking" them) they would find relevant to completing the task, while the test-operator then shows them the sketch that shows what window would open/close in response to their "virtual" click.

There's not a very capable online equivalent to it that I'm aware of. It'd be great if Zugg could somehow post some kind of screen sketches (I don't even propose to go as far as using a graphics program to make the buttons look real... Literally, a scanned SKETCH would do the job) and link them together like image maps, and propose a series of tasks to perform. Watching the traffic logs for those tasks could reveal what people click on, in what order, where they go back, find things out of order, etc. Could be pretty dang useful in creating a program that works like users would expect it to work.

/soapbox

Wizard Joined: 25 Mar 2003 Posts: 1113 Location: USA

I read over the list of features in the upcoming CMUD, and I'm very interested now.

I didn't see mention of anything that would allow regular expression aliases or sequencing of plugins, triggers, etc. Are there plans to add some of these features and you have only listed the ones that have been implemented thus far?

Something I enjoy being able to do in other clients is multiple matches on the same alias, even using different patterns. For example, I'll have a prompt trigger that fires and calls a special alias (__prompt), passing the values collected for health, mana, etc. The prompt plugin (or package) would have a default no-action alias to prevent any errors. Other plugins (or packages) would then have their own implementation of a __prompt alias and they may capture any, all, or none of the passed parameters, depending on their reason for wanting to detect a prompt. A plugin might need to know that a prompt has appeared just to reset a few flag variables, or it may be tracking health and mana to sip a potion.

Thanks for building a new, more powerful client for us all. I look forward to trying out the upcoming releases and writing some very useful packages.

Posted: Mon Dec 12, 2005 10:19 pm

Prototyping is great when you have lots of people working on something and have a lot of customers available for the testing. I have neither. Doing prototyping electronically via some sort of beta tester list would take too long, and I'd still never be able to please everyone. The reason most companies have to do serious prototyping like this is because they are not users of their own product. While I haven't played MUDs in a while (although I plan to start playing again soon), I am *very* aware of what MUD players need in a MUD client.

For me, it's always been easier and faster to just write something that I personally think is easy to use, then work out the needed improvements during the normal beta period. My background specialization is in user-interface design, and with the knowledge I have of MUDs, and my past experience from the 10 years of zMUD, I think I have a pretty good idea of what improvements are needed.

Besides, while prototyping sounds like a good idea, it rarely works well in "real like". In many cases, customers don't know what they want. They just want it "to work". And it's easy to get a biased customer base (like all advanced, or all novice users) and end up with an interface that still doesn't work well. Collecting actual useful feedback from a large un-biased customer base is the kind of stuff that some companies specialize in doing and costs a lot of time and money. Microsoft can do this kind of stuff with MS Office, but I can't afford the time or money for something like CMUD.

Also, just screenshots are not useful. It's how the program *functions* along with the user interface that forms the useability. When people just look at screenshots, they get focused on the wrong stuff. They start talking about fonts and icons, rather than the functionality. You can't try dragging/dropping with just a screenshot.

Sure, I can post a screenshot:

but what good is that. Ignoring the fact that the toolbars and menus are not completed, what can you say about this screenshot? It shows what it looks like when you are editing an alias. In this case, it's an alias written in VBScript. But you can't interact with this screenshot. You can't click on the splitter bar hotspots to see what they do. You can't click on any of the pulldown boxes to see what they do.

So all you can do with this screenshot is comment on fonts, colors, icons, etc. Add Theming makes most of the visual part irrelevant.

If someone wants to come to Colorado Springs, I'd be happy to invite them over and let them play with the user interface. But I think it's better to just wait until the beta release, play with it, and then tell me then what needs to be changed.

Posted: Mon Dec 12, 2005 10:24 pm

Larkin, the only features for the first beta release are the ones that I already mentioned.

You will be able to do regular-expression aliases using the OnInput reg-ex triggers, like in zMUD. You should start a different thread if you want to talk about that and discuss the things that you need to do that can't be handled by the existing method.

Currently, only a single alias/trigger/etc is called. If multiple settings with the same name exist, then the setting in the current class folder is called (or it's parent, or it's parent). But once a setting is found, the processing stops there. The idea of calling multiple plugins is an interesting one, and I'll have to think of how it might be done. But it can't really be done with the existing alias system because it would break any existing scripts that depend upon the current behavior.

For example, I have an alias called "kill" that exists in multiple classes. I enable one class when I'm using weapons, and I enable the other class when I'm using spells. When using weapons, the kill alias is "attack %1 with sword". When using the spell class, the kill alias is "cast fireball %1". (these are just made-up examples). So depending upon what class I have enabled determines what "kill" translates to. This is how zMUD and classes have worked for 10 years and there are lots of scripts that depend upon this. So I'd have to add something new, rather than changing how existing aliases work.

Posted: Mon Dec 12, 2005 10:46 pm

Oh, just for fun, here is the same settings file being edited in zMUD:

so you can compare the existing zMUD settings editor on top with the new CMUD Package Editor shown on the bottom.

Posted: Mon Dec 12, 2005 10:48 pm

Oh yeah, in addition to ignoring the toolbar, ignore the "tabs" shown (General, Settings, Config, Editor). That's just something for my debugging purposes.

Novice Joined: 16 Oct 2000 Posts: 43 Location: USA

Zugg, there's no doubt that your work with MUD clients makes you an expert on how MUD clients should work. So just because folks are thinking some UI review would be nice, it doesn't mean we as a group think your ideas suck.

But you don't have to do prototyping for the entire UI. I bet that you and Chiara could come up with a list of the ten most common "How do I...." questions that have popped up on the boards and in support e-mail. Those identify the spots where zMUD can use some improvement, whether functionally or in the interface.

As for your arguments against prototyping -- this is a classic argument that has been around since roughly the early Xerox PARC years. I'd take a moment to point out that you could probably knock together a runtime limited-functionality app in zAPP that you could distribute to your most trusted testers. The only functions the UI would have is to pop open menus and dialog boxes, nothing else.

Or, grab a copy of SnagIt or Camtasia and do a recording of you strolling through parts of the UI, and again send it to testers. You can get useful, valid feedback at low cost.

Posted: Tue Dec 13, 2005 12:16 am

Xymog, that's what I've already done. I already have a list of common support issues and I'm pretty well aware of which areas need the most attention. Obviously "corrupted settings file" is the biggest.

I guess the real issue is that the things that need the most improvement are really not "UI issues". Sure, there are some. The current zMUD settings editor is too complicated, and the big buttons along the top are not used enough to require them to take up so much screen space, etc.

But it's really a time issue. I can rapidly prototype stuff a *lot* faster than I can get useful comments. There are maybe a handful of people who would pay enough attention to the forums to make suggestions quickly enough. And that's a really biased set of mostly advanced users here on the forums. Doing prototyping with such a biased customer sample is actually worse than doing none at all.

The kind of testing that you are talking about is what I do during the Beta period. In fact, it's the main reason for the Beta period. UI issues can usually be improved very easily if the main program is designed correctly. It's much more efficient for a single programmer like me to program the *real* functionality, then release a beta, then tweak the UI than it is to do formal prototyping.

Xerox PARC used these arguments...but again, that's a big company with lots of programmers. It's not one guy who has been working on the same program for 10 years and intimately knows the field, like in my case.

Posted: Tue Dec 13, 2005 12:19 am

Also, I should remind people that I *do* value feedback of any kind. So if you have ideas for the UI or suggestions, then make *specific* recommendations. The reason I tend to have a very short fuse about this kind of stuff is that we have been over this ground before.

Remember the thread on the main zMUD forum about improving the UI? Nobody *ever* made the *specific* suggestions for improvements that I asked for. There is lots of talk about "zMUD needs a better UI", but nobody ever posts specifics on what they are talking about. It's always very vague.

The more specific people can be, the better the chance of having an impact on CMUD. Or at least when people are specific then I can give specific reasons why something isn't a good idea. Sometimes what one person thinks is a good idea is bad from the perspective of another. And over the 10 years of zMUD I've gotten a lot of feedback from all types of users via email so I do have a clue what works better for the majority of people. What works better is whatever results in less customer support questions ;)

Apprentice Joined: 08 Dec 2005 Posts: 108

I have an idea for you for UI:)
More and more of us are using dual screen monitors. Of that group, lots of us use laptops to do dual screen. So there are times when we switch back and forth between dual screen and single mode. Currently zmuds doesn't handle that very well. What would be great would be if you could add on option that woudl remember your dual screen settings and one for your normal settings, this concept could be expanded to have the CMud remember multiple window configurations. One the mud that I play I switch between 2 or 3 different window layouts on a common basis. I really do like the way you implemented the ability to have a a multiple windows and that we can drag them around. That is one of the most useful features of zmud. I love being able to drag my mapper to the second monitor and not have to expand the main program :)

Posted: Tue Dec 13, 2005 3:02 am

I use a dual monitor myself, and yes, CMUD will have better support.

The problem with zMUD was that it was written using Delphi 5, which has limited support for dual monitors. CMUD is using Delphi 7 which has all of this support and better Windows XP support built in.

GURU Joined: 24 Sep 2000 Posts: 1237 Location: USA

Seeing the Zugg-god has become annoyed, the meager user cowers a little, and meekly emits:

Didn't mean to imply you were a UI-diot. :) I just come down in favor of "test early, test often" (or "release early/often") when building a passionate (e.g. paying) userbase for software. Even if that means severely time/functionality limited demos.

Since the UI is obviously changing though, you've got to expect some armchair quarterbacking by the curious. Including me...

The sweaty-palmed user pauses... then continues...

For instance, from the screenshot above (I know this is early, and you could already have every intention of changing it, but I'll opine on what I got to see):

The icons down the left side are the traditionally used zMUD icons for variables, aliases, actions, etc. -- a past user might know that. But a new user would wonder (maybe even aloud): "What the hell is sliding man for? Or the gun?" I assume hovering over them would reveal a tooltip about what they're for, and that's the standard of most UI's now that try to fit a lot of objects in limited real-estate: show an icon with a tooltip. But sometimes conforming to what other UIs do could be improved upon...

Not very many other "tree-view on the left, pane on the right" UI's stick buttons left of the tree-view, so this will be unexpected. That is, the functionality will be an unknown issue, because it's not been seen before. I would propose, since many other UI's already do this: make a row of buttons on top of the tree/pane area (about where your tabs are now) and use both the icon AND the tooltip text for each button. Not only is it now where buttons are expected to be, but they're self-descriptive without having to move the mouse around doing roll-overs, AND they build word-picture associations for the user.

Not intending to further annoy the Zugg-god, the erstwhile user hastily adds:
That's the kind of feedback I think won't hurt, but might vastly help development, especially early on before too much functionality is already tied to everything; that I think early UI prototyping among a select user-set can produce.

The over-anxious user retreats into the crowd and hides behind some big guy.

Cool

Posted: Tue Dec 13, 2005 1:05 pm

*rofl*

Although your gurus plus some others could be trusted to have demo builds like you say this is a biased user base, but I do remember when you changed the settings screen in zMUD it threw me for six for a while so perhaps it isn't too bad an idea.

Novice Joined: 16 Oct 2000 Posts: 43 Location: USA

People aren't willing to give feedback when you dismiss out-of-hand the feedback you receive as being from know-nothing novice users or "biased" expert users. Novice user feedback is valid, especially since you *must* pursue the new user market in order to maintain and increase your revenue stream. Expert feedback is just as valid as those users can articulate better just *why* something isn't working and what alternatives may be available to do it better.

In terms of giving you specific feedback:

* I was product manager for ten years at two companies in the Seattle area that developed and sold PC-to-mainframe connectivity applications. They handled every form of "green screen" protocol, including telnet, Unisys, 3270, and 5250 data streams. These apps contained automation tools up the ying-yang, including handlers for external ADO, COM and VB calls. We had three complete UI revamps during that time and conducted usability studies on our products specifically because we *had* to be powerful enough for the command-line sysadmin and simple enough for the call-center temp worker. I managed the products through the Windows 3.x era, Win95, and Win2K eras. I am quite familiar with usability studies in general and the Windows UI in particular.

* You use nonstandard Windows UI design. At the basic level, the menu items are File, Edit, Tools, and Help. This is basic Windows UI design for all application types, whether document- or non-document-based.

* Edit | Preferences should be Tools | Options. Basic Windows UI design.

* Both global preferences (currently located under Edit | Preferences) and session-specific preferences should be located under Tools. Basic UI design.

* Toolbar contents change depending on what dialog the user is on. Toolbar contents must remain fixed unless specifically changed by the user. Basic UI design.

* A "New Session Wizard" is not available. Wizards are used for the most common tasks, or for ones that are easier to automate than to give written guidance through a help file. "New Character" takes the user to a dialog that has two Edit buttons. HUH? Optional UI component.

And this is even before I get into the session-specific UI, with its jumble of menu items, oddball toolbar options, strange window controls, and unexpected behavior ("Quit" closes out zMUD completely? Why not call it "End Session" and go back to the session launcher?).

So there you go, Zugg. You can continue your development model, and it works to an extent -- after all, you've made a living from it for, what, ten years? But if you're serious about improving your product's UI, then learn from the big boys. It's like playing tennis: you get better by playing against someone better than you, not by hitting balls against the back of the garage on a Saturday afternoon.

It's up to you whether you want to take the time to do it and what market you're going after. If you are after the sophisticated, MUD-savvy user, then perhaps you don't need UI changes (I'll let the MUD-savvy users speak for themselves). If you want to go after new users, then you should rethink some of your UI choices.

Posted: Tue Dec 13, 2005 6:03 pm

Xymog, you seem to misunderstand what I was saying. I wasn't saying that I wouldn't listen to people...I was saying that it is dangerous to base a UI design on limited and biased feedback. If I only got feedback from expert users, then I'd have a UI that novices would hate. If I only had feedback from novice users, then I'd have a UI that didn't work for expert users. That's a generalization, but since most of the users in these forums are expert users, it's not necessarily the best place to conduct useability studies.

But Darker already raises exactly the point I was trying to make about how useless it is to just post a screen shot:

1) Of course there are tooltips. Icons do not mean anything to new users. They are useful for advanced users who get to know what they stand for. It has become "standard UI" to use tooltips to help new users learn what the icons are for. In the past some programs tried using the "large button with icon *and* text caption", but this practice has become less common as tooltips became more widespread.

In zMUD, I tried the large buttons with icon and caption idea in the settings editor. It didn't help much. In fact, in some cases it had a bad side effect: by making the buttons large, some users thought that these buttons were really important. When, in fact, all these buttons do is filter the settings list. In fact, clicking one of these buttons can make some of your settings disappear (clicking Aliases makes everything except aliases disappear) and some people didn't really know how to make them come back again. So really, these "filter" buttons are performing a more advanced task that most novice users don't care about. Making this advanced task use such large buttons draws attention away from things in the UI that are more important.

So, that's why the buttons are now icon-only buttons (with tooltips).

As far as the location on the left...first, of course you can change this. You can drag/drop toolbars into any edge of the window, so you can put them along the top if you want. You can also customize each toolbar using a system which is similar to that used in MS Office so you can add commands to toolbars, rearrange them, etc. And all of this customization is saved between sessions. But that's for advanced users.

The default location of the left side of the screen is chosen because these are "filter" buttons, which are a bit different that buttons that normally appear on a toolbar. Novice users are used to the buttons on the top toolbar to be "command" buttons. The "Filter" buttons are like a giant radio-selection where clicking one button causes the others to unclick (unless you click with the Shift key help down, which is explained in the mouse-over help text that appears in the status bar). In a sense, the filter buttons act as the "mode" for the editor (you are in Aliases mode, or Triggers mode, etc). This is similar to graphics editors that put their various "tools" in a toolbar on the left or right side of the screen. These "tools" like line,brush,etc set the "mode" of the graphics editor. So placing the filter bar on the left is analogous to having a set of tools on the left. Having such a toolbar on the left is *not* unusual these days.

So yes, that's the kind of detailed thinking that has gone into the user interface. And none of this "design" is obvious from just the screenshot.

Sure, your feedback is important, but you need to remember that I'm thinking about this stuff 24x7! It's not like I'm just throwing together something at the last minute.

Going back to Xymog: This is *exactly* the kind of *detailed* feedback that I have been looking for. I can dispute some of what you said (whether it's "Basic Windows UI design" or just "Microsoft's latest fad" can be debated in some cases). But at least we can have a conversation about specifics. For example, I actually disagree with putting "Options" in the "Tool" menu. Sure, Microsoft does it, but does that make it right? Since when is "Options" a "Tool"? Sure, it probably doesn't belong in the "Edit" menu either. But this stuff moves around. Putting "Preferences" or "Options" in the "Edit" menu *used* to be standard. Until Microsoft came up with the "Tools" idea. But a lot of the stuff they put into "Tools" isn't a tool at all. In zMUD, the "Actions" menus should probably be renamed to "Tools"...that would make some sense.

And keep in mind that zMUD/CMUD *does* have some new concepts that are hard for new people to understand. After all, what is an Alias, or a Trigger, or a Status Bar item? zMUD has used the term "Settings" in the past to name this collection of stuff. They are not "Options", nor are they "Preferences", nor are they "Scripts". They are a weird collection of things.

And yes, Quit should be "Exit".

As far as toolbars, I agree that it was poor design in zMUD to have changing toolbars, and CMUD doesn't have any of that.

Wizards are a bit more debateable. Microsoft went crazy with the "wizard fad" and it's not always good. When you click the New button in zMUD, the instructions on the screen are quite clear:

GURU Joined: 24 Sep 2000 Posts: 1237 Location: USA

Actually, I wasn't hung up on the "do they have tooltips" issue. I assume they do, and would only be miffed if they didn't.

In fact, I was hung up on "what are they for?".

Until your response, there was no indication of filtering, and I'd apparantly have to mouse-over them to get that information in the status bar or tooltip. PS: I'll bet 70% of users ignore statusbars. If that's where the help is, I'd miss it.

It would make more sense to put a section below the tree-view that says "Filter" or "View Only:" and checkboxes or state-buttons to let me easily deduce that what's under the tree applies to the tree, especially if it's in the same "panel". Furthermore, the function of the buttons would then be self-evident. No hovering necessary. Faster visual understanding of function. Easier use. Happier user.

Wizard Joined: 10 Oct 2000 Posts: 1551 Location: Australia

My 2c on the buttons down the side... for me (and probably 90% of all users) you don't need to show those filter buttons at all, just have it 'show all always, no exceptions and don't show me the filter tool bar'. In zMUD I usually hit the 'trigger' button to edit a trigger, this opens the settings window with only triggers displayed which is sensible enough, but then I usually need to add a variable or alias as well, so I get frustrated with having to click the 'show all' button.

Maybe I'm the odd one out, but imo filtering is really an advanced user thing which even advanced user's don't use... so allow people to turn it on for 'compatibility', but have it hidden by default.

That's probably the kinda feedback that fits into the "you can't judge a book by its screenshot", but anyway :)

Posted: Tue Dec 13, 2005 11:02 pm

Darker, read my other post on the Design Challenge #2 and let's talk about filters there. Your idea doesn't work because there are too many settings types that you might want to filter on, including combinations of filters. It would take up too much space to have checkboxes for all of this. I somehow think there is a simpler solution to this.

Also, your comment about status bars isn't quite correct. Putting additional mouse-over help in the bottom status bar is becoming a common practice and is an excellent way to provide longer, additional help that a short mouse-tooltip can't provide. And with most applications, the status bar often goes unused.

Of course, zMUD is *really* quirky and puts the additional help in the main window caption bar, which won't be happening in CMUD...that was just too wierd.

In this specific case, the mouse-over hint says something like "Show Triggers" and the status-bar text says "Shift-click to select multiple types". So even if you don't see the status-bar text, the main tooltip already tells you what's going to happen when you click the button.

GURU Joined: 23 Dec 2000 Posts: 4834 Location: USA