Here I Go Again!

[Dullstar]

With that snapshot in mind, I don't think it would take up enough space to be a problem if you added in a scrollbar.  Other than that, great interface...

However, here's one of my ideas.

It's not great, but I don't spend too much time on these.

Note that the lvl is an abbreviation for level, not the format used by the original lemmings games.

[ccexplore]

[note: I'm still talking about GuyPerfect's mock-up; Dullstar's post came only while I was writing mine]

The current proposal is acceptable, and in fact is fairly similar to what Lemmix offers (except Lemmix shows it in a separate popup window, and has a vertical rather than horizontal list).  Some comments:

- I assume the pane can be turned on and off as needed (ie. it isn't always there).
- While the right-click-and-pan is a reasonably good alternative to a scrollbar, I can see some people might like the visual indication offered by the scrollbar's thumb, allowing a sort of visual-muscular memory to be developed for scrolling to a particular place in order to get a particular preset or object.

A possible alternative to scrolling could be a button that upon clicking, can expand the pane to full height/width, temporarily obscuring the level area but now can display several rows of stuff instead of just a single row.  Perhaps enough to show everything without scrolling.  The user clicks on the piece he wants and the pane snaps back down to normal width/height.

[Simon]

I hope that's a suitable alternative to a scroll box, 'cause I'm not liking the idea of putting a scroll bar in there.

It can be done, but a scrollbar is better for several reasons. Its usage is immediately clear to the user, and it provides, as ccexplore has hinted, more ways of control than other things.

Anything uncommon hampers the user. You appear to be using the operating system's GUI widgets already, so I strongly advise to use the common, known-by-all solution to this design problem.

-- Simon

[GuyPerfect]

However, here's one of my ideas.

That's pretty much how it's already set up, though I'm extra certain scroll bars aren't needed for the level display. The levels simply cannot be big enough to warrant the presence of scroll bars. As for the menu bar at the top, I'm still going back and forth on that one. The final product may not have one.

[...] except Lemmix shows it in a separate popup window, and has a vertical rather than horizontal list

I've already begun working on this interface, scroll bar notwithstanding. It can be configured to be vertical or horizontal and on any of the four edges of the screen. The size of the squares is dynamic, too, though I'm not entirely sure I'll let the user change that setting. It can be hidden, though.

While the right-click-and-pan is a reasonably good alternative to a scrollbar, I can see some people might like the visual indication offered by the scrollbar's thumb, allowing a sort of visual-muscular memory to be developed for scrolling to a particular place in order to get a particular preset or object.

Deal. This is a very good point made possible only by the presence of a scroll box. If you can see the relative position in the list of the object you want, you know that it's always "right about there." I'll adjust my layout accordingly.

You appear to be using the operating system's GUI widgets already, so I strongly advise to use the common, known-by-all solution to this design problem.

Thank you.

Why thank you? Because I'm not using any system UI controls, so the fact that you couldn't tell means I'm doing my job correctly. Everything's handled internally by the program and will look and act exactly the same no matter what system you run it on.

[ccexplore]

As for the menu bar at the top, I'm still going back and forth on that one. The final product may not have one.

Hmm, I'm curious how then you intend to surface visible entry points to commands like saving a level.  While you can potentially have no visible entry points and just use keyboard shortcuts, it can be frustrating if someone forgets what key to press.

===========

I still think having an option that can avoid scrolling/panning altogether is worth considering.  Like the "expand to several rows" button I mentioned, although some user-testing may be worthwhile to see whether it's too disruptive or not (I don't think it is, and the user's not forced to use it, but...).  This was also why I earlier suggested the mini-map thing for jumping to particular areas of the level, as a potentially faster means than scrolling/panning to get to where you want.

[GuyPerfect]

There's any number of other ways to access features graphically without using a menu bar.

Anyhows, the introduction of additional UI elements has brought to my attention a need to modularize the handlers for user input. This isn't something I've had to do in the past, so I still need to think about the best way to go about it. That said, I'd expect a couple more days before I have any new updates to report.

[Dullstar]

Wait!  I have an idea!

The buttons in your mockup, GuyPerfect, could be held down so you wouldn't have to click-click-click through, and somewhere you could have something to the effect of a menu bar (that performs the proper functions, anyways.)

[ccexplore]

There's any number of other ways to access features graphically without using a menu bar.

Of course, but seems like a menu bar would take up the least screen real estate compare to other alternatives.  What do you have in mind instead?

[GuyPerfect]

News, everyone!

I've come up with a good method for modularizing user input between controls, and it's effectively the same as the one used by existing operating system UIs in use today. My project, however, is basically just the one interface (the level editor itself) with a bunch of shared variables thrown here and there and it's intermingled directly with the user input handler. The first thing I'll need to do is disconnect that interface and make it float out in space all by itself, then make each new interface similarly buoyant. Lo and behold: I'm having a little mini-application of what I started this project for in the first place. Go figure!

Achieving this task will require a significant reorganization (not to be confused with re-writing) of the existing code and will take the free time of a couple days to do correctly. However, this turn of events comes with its fair share of advantages. Since I'm in revision mode, I'll take a careful look at each existing function as I move it over into a new project and ensure it's all up to snuff and coded correctly. This will make the program's structure cleaner as well as ensure it comes out bug-free. Also, since the new project setup will require the editor to be instantiated, I might as well throw in the capability of having multiple levels loaded at any given time.

I'll post something more when I have something to report.

[Dullstar]

Whatever we use, it's supposed to be cross-platform, right?

Linux users are standing by...

[GuyPerfect]

I'll have to get Linux installed on my machine so I can test the project there and make sure it compiles correctly. The Linux version will more than likely be released a few days after the Windows version.

[Dullstar]

If you send me the files, I'll do it.  You don't have to install Linux if you don't want to.  I do have a C capable compiler on my machine, although I don't know if that'll be enough.

[GuyPerfect]

gcc and xorg-dev or whatever it's called will do the trick. But I do want to install Linux. I've got a couple empty partitions on my hard drive from when I installed Windows for just that very reason. I simply haven't gotten around to it yet.

[Dullstar]

Hey, nice.  What distribution are you installing?

[GuyPerfect]

Debian, but I don't suppose that's a discussion for this thread. (-: