These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Test Server Feedback

 
  • Topic is locked indefinitely.
 

Please put option back in....

First post First post
Author
Prometheus Exenthal
Aliastra
Gallente Federation
#161 - 2011-11-24 14:18:15 UTC
Keep the pinning.
I would say that the edge delayed drag wouldn't be as effective as you'd imagine.

This is largely because many players have their chat windows taking up a large portion of the screen.
Making the delayed drag an edge only option would mean that anything that is elsewhere is still the most prone to being dragged and such..

A great step would perhaps be to make only the title and bottom bars of windows the only portions of windows that would allow dragging and shrinking. This would HUGELY reduce the frustration involved with the 'Selected Item' and overview windows.

I would not remove any of the current features, but maybe streamlining is a good idea.

Perhaps, anything pinned has a good drag delay rather than being totally pinned and immobile.
Say, a 1.5-2 second hold-click before the item moves.

One thing I would personally love to see is that when collapsing windows that are currently snapped in proximity to another window, snap to their bottom edge or top edge, depending on their screen placement. That, and dragging any windows that are snapped to its top edge, down with it.

As for the background fade, please no.

https://www.youtube.com/user/promsrage

DO YOUR JOBS, CCP DEVS. FIX THE GAME INSTEAD OF FKING IT

Depili
Perkone
Caldari State
#162 - 2011-11-24 14:18:20 UTC
CCP Optimal wrote:
Collapsing windows has always seemed like a weird little thing to me, and for some reason it always reminds me of Windows 3.11, which is less than great. Do people use this feature? I know that some people use TAB to collapse/expand all windows, but wouldn't it make more sense to minimize/maximize all windows instead, while allowing you to exclude some windows (such as the overview)?


Coming from unix background I have always been using window shading (collapsing them to just the tittle bar) and find it very useful. This way the window location stays where you left it and it's easier to come back to than hunting some obscure minimized window bars mixed in the chat stack at the same location.

When I use tab myself I want everything gone from the screen so that I can manually pilot or position probes without any windows taking up the screen, and even leaving the overview would leave a sizeable chunk of screen estate unusable as an overview showing alliance, corp tags, type, name, speed, distance takes lot of space. Such exclusion list needs to definitely be user configurable.

For the tab behavior I would very much like it to be changed so that it has zero memory on what it's doing so that: 1) if any unshaded windows shade them all 2) if no unshaded windows unshade them all. Currently for example when using it while probing and shading everything via tab, then unshading just the scanner window manually and then pressing tab first shades the scanner window back (good so far) but pressing it again unshades just the scanner window, not all windows...
Two step
Aperture Harmonics
#163 - 2011-11-24 14:19:27 UTC
My view is that you ought to stick to standards more. I suspect that 90% of the folks that lock windows do so because for some reason, you allow people to move windows by dragging their backgrounds. This is not "normal" behavior, and is annoying.

The only time I use the tab key to collapse all windows is when the overview is bugged and I want a quick way to refresh it. This has been mostly fixed recently.

My #1 windowing UI complaint is that you guys don't make the enter key always map to OK in dialogs. This is especially visible in the industry UI, where after picking a manufacturing location, enter will re-pick the location, rather than hit the OK button. You appear to have enter activating the focused control, not the default button for a dialog, and it is annoying.

CSM 7 Secretary CSM 6 Alternate Delegate @two_step_eve on Twitter My Blog

Depili
Perkone
Caldari State
#164 - 2011-11-24 14:27:45 UTC
CCP Optimal wrote:
What about features like SHIFT-dragging windows to drag an entire snap-group of windows ... is this the first time you ever heard of this or is it a keeper?

Are there other weird little things in the window system that nobody uses that we could probably axe without much rage?



Never even heard about that shift thing, as there isn't any documentation available on the UI for players much less a tutorial on it's features...


Can't think of anything to axe but can think of one simple thing that is pissing me off: the default window behavior when enter is pressed on a window that has focus:

1) the DT notifications get it right and close with enter, good
2) The plex messages I have seen maybe thousand times (and read maybe half of the text ever) don't close with enter, you have to mouse click on the close button... always instinctively press enter first.
3) The mess that is the install job dialog in science and industry:

The default action on the install job dialog seems to depend on from where did you start the job (hangar/assets/s&i window blueprint list) and also from what you did last on the dialog, for example selecting a decryptor for invention job makes enter no longer submit the form and get a quote. Sometimes enter starts going to the select installation screen, sometimes popping out the select decryptor field...

Same failures are in the select installation dialog; if you for example select the public/corp/alliance installation filter enter no longer submits but instead pops up that selection box. (also why don't you have sane selections on the range filter, like "installations this job can be installed on" by default as manufacturing on a tower remotely necessitates the usage of "region" filter).

The whole mess screams to me that you don't have a sane class structure going on with the windows where there is a basic window class, a class for pop ups etc that all the windows inherit from, such a structure makes it trivial to maintain window locking and good defaults on what happens with enter so all pop ups behave the same for example.
Depili
Perkone
Caldari State
#165 - 2011-11-24 14:30:37 UTC
Two step wrote:
My #1 windowing UI complaint is that you guys don't make the enter key always map to OK in dialogs. This is especially visible in the industry UI, where after picking a manufacturing location, enter will re-pick the location, rather than hit the OK button. You appear to have enter activating the focused control, not the default button for a dialog, and it is annoying.


Seconded, make enter do consistent things on all windows (close on pop-ups, submit on forms)
Dr Mercy
BreadFleet
Interstellar Triglavian Collective
#166 - 2011-11-24 14:39:43 UTC
CCP Optimal wrote:
If we were to go down the LUA path, that would mean re-writing the entire UI, which would take multiple man-years. In the meantime we would of course not be able to do anything else which would ... kind of suck wouldn't it?

The thing about making everything customizable is that it makes the code, windows and system menu more complex to work with, for users and developers alike. This is of course an eternal tug of war between simplicity and customizability. If everything is customizable, programmers and designers will have to account for all combinations of options whenever they change anything, so the complexity obviously grows exponentially, the end result being that more time is spent on maintenance, and less time on improvement. Of course I'm not saying that you shouldn't be able to modify anything, but we do need to make a solid case before adding more stuff to the system menu.


Does it reduce to workload sufficiently if only certain elements are converted to LUA?

Make isk with PI: http://failheap-challenge.com/showthread.php?1207-What-to-do-PI-Processor-only-planets

Alysia Blaine
The Scope
Gallente Federation
#167 - 2011-11-24 14:53:08 UTC
Please keep the window pin option, or i will delete EVE Online.
Depili
Perkone
Caldari State
#168 - 2011-11-24 14:54:57 UTC
Reading the replies that came when I typed my walls of text the idea of having separate customizable hud and windows seems quite logical and sane way to go with it, thus you would have a special mode to configure the hud, including placing the cap/hp readout where ever you wanted it, placing the module grid where you want (independent of the cap readout) the overview, selected item, drone window and fleet window lite (which only shows last few broadcasts and the broadcast buttons, really dislike the decision to pair the buttons and broadcast history with the fleet window). All the HUD elements should be unmovable outside of this special mode.

Many people don't even seem to know that you can move the target bar and even get it vertical if you want to as it's all hidden away on a really hard-to-see little cross that is often bellow windows.
CCP Optimal
C C P
C C P Alliance
#169 - 2011-11-24 14:59:02 UTC
Two step wrote:
My view is that you ought to stick to standards more. I suspect that 90% of the folks that lock windows do so because for some reason, you allow people to move windows by dragging their backgrounds. This is not "normal" behavior, and is annoying.

The only time I use the tab key to collapse all windows is when the overview is bugged and I want a quick way to refresh it. This has been mostly fixed recently.

My #1 windowing UI complaint is that you guys don't make the enter key always map to OK in dialogs. This is especially visible in the industry UI, where after picking a manufacturing location, enter will re-pick the location, rather than hit the OK button. You appear to have enter activating the focused control, not the default button for a dialog, and it is annoying.


This is a great point. Would most people agree that reducing the draggable area for a window to the window header would eliminate the need for locking? I assume the same would be done for collapsing as it doesn't make a great deal of sense that double clicking the window directly collapses it and probably causes a lot of accidents.

We strive to have ENTER work as confirm for all dialogs. If some of them fail to follow that pattern, I would call that a defect.
Lady Spank
Get Out Nasty Face
#170 - 2011-11-24 15:00:29 UTC  |  Edited by: Lady Spank
I pretty much like the ability to know that if I lock a window down it isn't going to go ANYWHERE without using the tiny buttons on the top right. I don't know how many other people feel this way but I can't be the only one.

CCP Optimal wrote:
In the case of locking windows when pinned, I take it that the biggest reason for the usage relates to lightning fast mouse maneuvering and button pressing going wrong and the usual suspects being the overview, selected item and drone windows, and probably any other combat related window. I would be surprised if many people lock their fitting window (or do they?). Maybe the solution could be as simple as making windows, that have been snapped to a screen edge, or other windows, harder to accidentally move, so that the window wouldn't start moving unless you had dragged it, say 5-10 pixels? Maybe the windows in question shouldn't be windows at all, but rather fixed to the right hand side of the screen (similar to the the ship HUD)?


Pretty much got it in one here, although I dont agree about the snapped to other windows bit, sometimes things have a little seperation like so...

http://i.imgur.com/YZOgY.jpg

Thats on a rather small window res but as you can see the selected item window is seperate (although still tied to the side of the screen. At times, on larger res settings you might have something pinned neared the middle (like a watch list, scanner drone window etc which are completely seperate but still wish to have pinned.

At present the modular nature of the overview allows for a variety of different settings to suit the myriad roles you may end up in in eve, from mining ops, solo pvp, trading and of course larger scale fleet ops that require many more windows (intel channels, watch lists, fleet window blah blah blah... being able to treat each element seperately is fantastic allowing you to scale back when you dont need so much clutter.

I remember when the overview, selected and drone bay were all forcibly grouped on the left and it could be frustrating at times (althogh admittedly it was also rather buggy at times too)!

Thanks for being 'transparent' on the functionality of the windows # Ba-dum tish! #

(ಠ_ృ) ~ It Takes a Million Years to Become Diamonds So Lets Just Burn Like Coal Until the Sky's Black ~ (ಠ_ృ)

Ismaus Taeus
The Scope
Gallente Federation
#171 - 2011-11-24 15:07:35 UTC
CCP Optimal wrote:
If we were to go down the LUA path, that would mean re-writing the entire UI, which would take multiple man-years. In the meantime we would of course not be able to do anything else which would ... kind of suck wouldn't it?

The thing about making everything customizable is that it makes the code, windows and system menu more complex to work with, for users and developers alike. This is of course an eternal tug of war between simplicity and customizability. If everything is customizable, programmers and designers will have to account for all combinations of options whenever they change anything, so the complexity obviously grows exponentially, the end result being that more time is spent on maintenance, and less time on improvement. Of course I'm not saying that you shouldn't be able to modify anything, but we do need to make a solid case before adding more stuff to the system menu.


Actually, no that isn't a bad idea. That way, when you do finally update the game - say this would've been a decision made in 2007 - years spent coding the new UI would pay off. So lets say you start today. No other dramatic updates for a couple years. People would be that much more appreciative of your hard work.

But it isn't as profitable when you risk losing players, now is it? C'mon, if anything I've learned from EVE is that time IS money...

But, honestly, I've heard time and time again, forum after forum, that when it comes to changing the UI or enabling efficient customization/OS compatibility it will take more than an arm and a leg to apply such a change. Don't get me wrong, I think your jobs are great adding new features and all but... i wouldn't imagine a small team working on a UI overhaul, if you didn't have to. I'd doubt the impossibility if a practical assessment of the potential workload can't be made. I've seen freelancers do lots with no money. All they needed was a plan, and just a pinch of ambition.

What I'm saying is if YOU, CCP Programmers & Staff, wanted to change things you could. You already have an income source, and I've seen people with less at least attempt at doing more. But I assume the reality of that is just too much for me to understand? Don't worry, I do. I think you're doing an excellent job, and you've got your hands Full with the upcoming expansion. Please, do carry on.
Dibsi Dei
Salamyhkaisten kilta
#172 - 2011-11-24 15:11:14 UTC
CCP Optimal wrote:
Collapsing windows has always seemed like a weird little thing to me, and for some reason it always reminds me of Windows 3.11, which is less than great. Do people use this feature? I know that some people use TAB to collapse/expand all windows, but wouldn't it make more sense to minimize/maximize all windows instead, while allowing you to exclude some windows (such as the overview)?

Removing collapsing is fine with me.

But if you decide to keep it please make it so that the window collapses ONLY if you double click window title bar. (or press tab)

Collapsing windows are the most annoying thing in the world, especially when it comes to the selected item window. Accidentally miss the buttons and the window collapses and your target warps away.
Sessym
Ministry of War
#173 - 2011-11-24 15:31:21 UTC
CCP Optimal wrote:
Two step wrote:
My view is that you ought to stick to standards more. I suspect that 90% of the folks that lock windows do so because for some reason, you allow people to move windows by dragging their backgrounds. This is not "normal" behavior, and is annoying.

The only time I use the tab key to collapse all windows is when the overview is bugged and I want a quick way to refresh it. This has been mostly fixed recently.

My #1 windowing UI complaint is that you guys don't make the enter key always map to OK in dialogs. This is especially visible in the industry UI, where after picking a manufacturing location, enter will re-pick the location, rather than hit the OK button. You appear to have enter activating the focused control, not the default button for a dialog, and it is annoying.


This is a great point. Would most people agree that reducing the draggable area for a window to the window header would eliminate the need for locking? I assume the same would be done for collapsing as it doesn't make a great deal of sense that double clicking the window directly collapses it and probably causes a lot of accidents.

We strive to have ENTER work as confirm for all dialogs. If some of them fail to follow that pattern, I would call that a defect.


I must both agree and disagree with most of the people then Big smile
In a heated situation you shouldn't be able to drag something accidentally. I usually lock all my windows when I'm out in the wild. I'd prefer to keep this functionality...

Speaking of Interface... Doesn't CARBONUI allow you to do pretty much whatever you want with the controls?

[b]_____ ,,,,,,,,,,,,,;;;;;####;;-------======-]> --,,,,,,,,,.... //_###_____------;;;;;;;;;;;;'''----======-]> --'''''"""" //_/ -------[/b]

DelBoy Trades
Trotter Independent Traders.
#174 - 2011-11-24 15:34:10 UTC  |  Edited by: DelBoy Trades
CCP Optimal wrote:
Would most people agree that reducing the draggable area for a window to the window header would eliminate the need for locking? I assume the same would be done for collapsing as it doesn't make a great deal of sense that double clicking the window directly collapses it and probably causes a lot of accidents.


No, I think one of the main reasons for windows flying all over the screen is over-zealous camera spinning, so you left-click randomly and launch your mouse across the desk to get a quick 360 around you, the problem arises where you accidently snag a window, with it reduced to headers, you're less likely to snag one, but the chance is still there. A proper pinning tool, would stop this all together.

Edit: Double clicking the header by accident and collapsing the 'Selected Item' window annoys the jesus-juice out of me, especially when you're trying to make a quick get away or lock up a target.

Damn nature, you scary!

Depili
Perkone
Caldari State
#175 - 2011-11-24 15:36:42 UTC
CCP Optimal wrote:
Two step wrote:
My view is that you ought to stick to standards more. I suspect that 90% of the folks that lock windows do so because for some reason, you allow people to move windows by dragging their backgrounds. This is not "normal" behavior, and is annoying.

The only time I use the tab key to collapse all windows is when the overview is bugged and I want a quick way to refresh it. This has been mostly fixed recently.

My #1 windowing UI complaint is that you guys don't make the enter key always map to OK in dialogs. This is especially visible in the industry UI, where after picking a manufacturing location, enter will re-pick the location, rather than hit the OK button. You appear to have enter activating the focused control, not the default button for a dialog, and it is annoying.


This is a great point. Would most people agree that reducing the draggable area for a window to the window header would eliminate the need for locking? I assume the same would be done for collapsing as it doesn't make a great deal of sense that double clicking the window directly collapses it and probably causes a lot of accidents.

We strive to have ENTER work as confirm for all dialogs. If some of them fail to follow that pattern, I would call that a defect.


Reducing the area which can move the window would help and makes perfect sense when looking at other common windowing systems; none of them have similar functionality as eve does where you can drag window around by dragging the window contents. But in addition to this I would prefer to have lockable windows as there is zero need to reposition the "combat ui" once it's been set up.

For the enter thing start with plex popups and work your way to the mess that is S&I windows, plenty of stuff to do there regards what happens with enter.
Arkady Sadik
Gradient
Electus Matari
#176 - 2011-11-24 15:37:45 UTC
CCP Optimal wrote:
Would most people agree that reducing the draggable area for a window to the window header would eliminate the need for locking?
Hm. Tentative "yes" from me.

I think the only time I actively used something else than the header for dragging was when I had a window jump around and actually move out of the interactive area, leaving only the bottom and right part of the window visible. The last time this happened (to a chat window which couldn't be dragged with anything visible), I used another window to snap to the chat window and then shift-drag to make the original window fully visible again.
Sanche Tehkeli
Bionesis Technologies
#177 - 2011-11-24 15:55:20 UTC
There are several annoying things with the UI imo.

A 'pinned' window doesn't modify its tabs behavior, and that's a pain. When I 'pin' a windows, I'd like to have tabs inside tabbed as well, so that if i click-drag accidentaly on the tab label it doesn't move. Especially annoying when you have multiple channel tabs on screen.

Resizing a window is limited by your anchor/minimal size code, I'd like to size windows the way I want, even if too small. Drone Bay, Cargo, Fleet etc have weird settings with minimal size. With point #1 above, when pinned they should not be resizable. In addition, some tables in window do not memorize their columns width, or adjust width automatically (like cargo bay) even when it's not desired.

In fact, i'd like to have a option to really "freeze" up UI to be sure widgets cannot be affected in any way except for few, standard, and well-explained stuff (minimize, close commands for example.)


There are several 'little things' (all things equal) which could add some awesomeness to in-space view : make the solarsystem and star maps an overlay of the in-space view, instead of or in addition of the actual modal view. This layer could require a hotkay pressed to interact with, but it should first mirror the map to the view. So, with stargates aligned to their actual destination, with additional stars in space to mark neighbor systems, one could see the map overlay (with routes, or security system color, or "ennemy spotted" broadcasts, cynos, ships destroyed in the last hour, etc.)

I didn't verify on Sisi yet, with new jump drive effect, does the effect end with the distant ray points to the actual jump destination ? If yes, awesome, if not, it is need.

This could add emergent intel gameplay. You see a capital jumping out, with the overlay with current open cyno you could guess its destination.
Palovana
Inner Fire Inc.
#178 - 2011-11-24 16:03:31 UTC  |  Edited by: Palovana
Just in case it helps, an overview of my screen setup.

In space, I pin the Selected Object window, the Overview window, Chat (stacked) windows, Fleet window, Drone window, D-scanner and Cargo windows (when looting wrecks, you don't want your Cargo window changing locations and it sometimes does this on Sisi now).

I do NOT snap windows all the way to the edge of the screen however, I leave a "gutter" around the edge of the screen, this is so brackets for things behind you, etc can be seen at the edge of the screen and not obscured by the windows.

In the station, the Selected Object, Overview, Drone, and D-scanner aren't available BUT I still keep the remaining pinned windows pinned in place, plus I stack (but not pin) the Items, Ships, and People/Places window - in the same location that wreck windows pop up when looting.

In the station I also pin the Station Services panel, since there are no brackets in the station to deal with, this one IS snapped/butted to the right side of the screen, usually the full height top-to-bottom.

Market, Fitting, Jukebox, S&I, Contracts, Mail, etc windows don't get pinned.

For a UI, I prefer familiarity and functionality over shiny effects. Example: I stopped using Ubuntu because of the Unity interface replacing classic GNOME, and switched to Xubuntu (using XFCE which is more like classic GNOME).

Screenshots from Sisi, I've noted window statuses and marked the "gutter" area that I keep window-free in space so the brackets for off-screen objects can be seen:

Station Windows (JPG, 1920x1200)
Space Windows (JPG, 1920x1200)

Limiting the window movement to grabbing the titlebar would be helpful but still not perfect, because grabbing a window edge or corner would still cause it to resize and cover other windows or other vital information.
Mag's
Azn Empire
#179 - 2011-11-24 16:19:01 UTC  |  Edited by: Mag's
Sessym wrote:
Speaking of Interface... Doesn't CARBONUI allow you to do pretty much whatever you want with the controls?
You bring up an interesting point. Thinking about it now I thought we had moved over to carbon, or is it only parts of the UI that have been carbonized?

Oh and I too will say a tentative yes to the limited drag area, although locking would still be the better option for me.

Destination SkillQueue:- It's like assuming the Lions will ignore you in the Savannah, if you're small, fat and look helpless.

Castellan187
Deep Core Mining Inc.
Caldari State
#180 - 2011-11-24 16:55:00 UTC
As above. I like the locked windows. I'd appreciate (if you scrap locking all together) the limited drag space. But then clumsy me would still manage to drag and resize windows. And would they then still be more see-through than other windows?
Would much prefer pinning to mean "locked in place" though...