User Interface / Hotbars

[andy310]

Dear Turbine,
Firstly, I'm grateful that you decided to apply my suggestion on the /ui to save load the hotbars. I and I'm sure the whole community appreciates the effort that went in on that.

I again would like to suggest something for the UI that might make DDO a lot more enjoyable for everyone.

There's a miriad of reasons why the current Hotbars are a problem, and this thread is not to discuss any of that but, to simply show a superior engineered way to achieve a better game-play and spend less time tinkering with the UI instead of USING it.

My goal with designing this concept, is to allow for an interface to EASILY scale from 1 screen res to another.
Perhaps I am the only DDO player on earth plagued with the issue that whenever I can't play on my main computer, I have to mess around endlessly with the hotbars, which compared to playing is definitely no fun.

The concept is simply stated, a mostly "matemathological" elaboration of a concept I have long had called "Grid System".

Simply put, and for those of you who aren't Turbine or Don't care about the inner workings, It's a UI system that allows you to place clickable items anywhere you want them to be, based on your choice of binding corner. Thus allowing the MORE or LESS clickable fields to be visible depending on your current screen size.
The system will also allow you to Mass select and move around the clickables you populate, or designate areas to always be on screen.

That's really all you need to know to undersign unless you're into the Geeky programmatical logistics of achieving this UI approach, in which case, you should continue reading on

Grid System: Clickies everywhere on the screen; Separated, Spaced out so that they don't overlap.

So, my Grid System would basically be comprised of 2 major sections;
The Builder section, and the Usage section.

Let's firstly go into how the grid should be generated programmatically and logistically:

Upon loading of the game, when the screen res is checked, the game system should programmatically calculate just how many clickies can fit into the screen;
I'm rather sure that there's an available variable with the value of the internal boundaries of the screen width and height, but say there was not, it's easily calculated by checking if windowed or full-screen and subtracting the frame size from the screen resolution. Without getting way technical, here's a scenario with some rather simple coding work which would actually allow to calculate and obtain specs on a user's grid:
Across: round down ( screenWidth [ - windowed_frame_size if present!] / (width_of_clickable_field + 2*width_of_clickable_outer_frame) )
Vertical: round down (screenHeight [ - windowed_frame_size if present!] / (width_of_clickable_field + 2*width_of_clickable_outer_frame)).

Where Currently the width_of_clickable_field is 32 Pixel and the width_of_clickable_outer_frame is 2 Pixel per side. - And factually, I could see this being cut down to 1 Pixel...

Let's say my screen res is 1366px by 768px, which in Web Design standards is fairly common on laptops. Now I play windowed so the internal size comes down to ~1350px by 730px. Our math gives that 1350 / (32+(2*2)) = 37 (.5 but round down), and 21 (.3~ again, round down.).

This would mean that I can place up to 777(37X21) clickables into my screen if I'm Ok with completely cluttering the field of view.

Let me take into account the current UI, the top icons, the bottom XP bar, the chat etc. which can programmatically be built around since the layout saves up positioning and sizes in order to restore it. (mostly think of the party chat). Let's just remove the width*height surface area of the chat from the grid altogether, and shrink by 1 row of clickables for the xp bar at the bottom.
Let's say my previous number was wrong by about 2 vertical lines altogether, so it's 703 fields for accuracy's sake. Point is, a grid is calculated and ready/drawn on screen ready for usage.
Let me specify that This grid is invisible and only the portion around a clickable box becomes visible (2 px all around) when the clickable is position from within the Build section.

Last Programmatical thing to cover would be the Grid Enumeration.
How do we "remember" which items are where, and what is that based on?
Firstly, let's allow players to choose their "Bind Corner".
This will start generating the grid from one of 4 different corners, thus NOT moving the items around for many of us.

I'll stick to my Bottom Right hand corner, so the enumeration should go 1 to 0 from the BOTTOM RIGHT corner, to 10 cells vertically. The next 10 cells should be moved to the left by one column, and enumerated 10-20, and so on. (playng the old SNAKE for Nokia anyone?)

When Items are placed into cells, the system will memorize their Neighbor's Content, and enumeration. Upon any game load, where the Enumeration memorized doesn't match the factual content, the fields will be shifted and re-created on our secondary grid, left-bottom to top right, based on memorized contents. Thus, when changing resolution and dropping about 10 cells from my lef, I will find a block of 10 cells where I had clickables in my Overflow for within the builder.

Usage Section:
This is the "visible" or "populated" part of the grid, that houses our clickable items, allowing users to quickly click the item just like the task bar. Possibly subject to the same Skin features that I think are available on the current shortcut bars, this is basically the end product of all the coding work logistics above, when interpolated to the Builder section used to populate and designate the areas.


Builder Section:
Now let's go into this... After-all, this is really where the usability and user friendliness comes into play.

Through the menu, instead of "lock shortcut bars" we'd have a button to render the grid "editable". Ticking this button will overly the transparent grid onto the screen for players to see where they want to drop their items.
SINCE we left space of rows out from the bottom (for the XP bar), we can overlay this space and place in clickable controllers that allow our different actions to take place. Described below are the actions:

Designate Visible fields:
This button would allow you to Click and select which grid fields you want to always display. regardless of whether you have items within or not. This will be useful for generating custom places where a player can quickly drop in an item as those gained from a quest (flesh to stone anyone?) Simply SHIFT+click similar to how EXCEL's cell selection works.

Designate Shortcut Fields:
This will allow the user to select which section of 10 icons across will function as the HotBar, generating an holder accessible though keyboard shortcut 0-9.
Or to manually click in order which fields to tag to the keyboard bindings (Clicking count should start at 1, and change to 0 when >9, so as to maintain the order of keyboard layouts).

Easy Populate:
Very simply places all the <item> you have available on the bar, left to right starting at bottom of the screen and moving up. This should have an overlay to include, Active Feats, Active Skills, Spells (Perhaps only prepped ones), clickable Items, Active Enhancements, etc.

Grid Overflow:
This will simply display a secondary grid Shadowed in gray over the active one. the items ordered within have maintained their original relative coordinates (Relative square to square, not X to Y on screen), where all of the items that were linked to a part of the grid that is no longer visible on screen have been shifted to. The idea here is that a player can SHIFT+CLICK to select parts of the items, Move them around over an area that is empty in the actual grid and right click the selected clickables to "move to active grid".

I think I will be expanding on these current features.
I will likely also create a web based demo after new-years, just to see how factually items can scale in and out at different resolutions. Anyway, the really nice thing about this is that it wouldn't take me more then 1 week to code without even having ever seen whichever application's source-code. It extremely simple to use the pure logistics presented above and re-code a UI for just about any MMORPG out there. I am amazed that no one has actually implemented something in an even remotely similar fashion to what I just described in (possibly too much) detail.

PS:
IN the mean time, you could maybe have the hotbars snap onto one-another when placed near? that would already help a bit with time consumption upon resizes...