RomRaider

I have my own, admittedly strong, views on this subject, which I'll lay out below. I'm doing this because you guys already use it and I want to know how you feel about my ideas, and what your own ideas are. I expect some of this has been covered before in other threads, feel free to link them here, especially if you do some cherry picking of gold from them to raise the quality of this thread and keep the signal to noise ratio high.

Possible Styles

An app like this can be designed and built in multiple ways. There are obviously an infinite number, however there are a few obvious choices which I'll list here.

1) Tabs. Have certain functions in certain tabs and others in others. Manually mix them up in the code to create useful combinations. Downside: Other combinations are not possible without hacking and it takes work to produce these combinations in the first place. Not ideal.

2) Separate windows for separate functions. You can have all of them open at once, but resizing things and moving things around is painful. Especially on windows he title bars are HUGE and it's an inefficient use of available screen real estate. Not ideal.

3) One giant scratch space and embedded mini windows with different things in them. This is close to what RR already has. This is also my preferred layout. I consider this ideal when combined with a profile-like functionality enabling you to save and restore arrangement and content state. For example, I want main VE, main ign timing below it, and a set of flags across the bottom and some gauges down the right. Save, close, come back next week, open, restore, smile.

What's Wrong With RR

From my perspective, there are two main things wrong:

1) The list of data areas on the left is "hard coded" (by design) to be there and only there and always there.
2) You can't throw in some other windows holding gauges and state display and a 3d view etc. They must be separated.

What I'd Like To See

Therefore what I'd like to see is that the logger components, currently in tabs, be moved to possible window options much as the tables are now. I'd like the data list to be one too. I'd probably throw a menu in with a list of available components maybe with some prioritised. For example, you'd want to be able to bring up the data list easily/quickly, so put that in a subsection of the menu at the top. Ditto the quick click button links to other main items. Don't force menu use to get key components, give a quick launch component that mirrors a subset of the menu functionality. etc.

Additionally, and I'm not sure if this is possible/feasible or not, I'd like to see the native look title bars for the internal windows go away. They, as mentioned are HUGE on windows, and on a typical 1280 800 tuning laptop eat way too much space. Some sort of minimal title bar setup with an RR look/feel across platforms would be superior IMO.

Keeping it at the user's discretion maximises the usable real estate that they get. Forcing certain buttons and controls that are not applicable to everyone's tastes is less than ideal IMO.

Thoughts? Your ideas? Attack freely, I have a thick skin :-)

Fred.

Something like this:



There are things to hate about the above, such as the huge win internal windows, and some of the components are average, but the basic idea of having components and a maximal space for them is solid IMO.

Fred.

Well, just to be clear.. when you say "tuner" do you mean integrating the entire editor or just adding RAM/Live table tuning to the logger?

I like the idea of full integration.

I think the parameter selection tab should stay as it is, as a "side toolbar" that is easily hidden. In that toolbar space there should also be a toolbar for table selection. And any selected table spawns its own separate window. If the logger is connected to that particular CALID, the table window either automatically, or has a button to, start logging the table axis parameters to display the current load cell. RAM tables display as null values with a message when proper CALID is not connected.

Things like Maf tab, injector, dyno, etc. Would be better placed in a "tools" entry in the top menubar. Like the above tables, spawning in a new windows with an 'enable button' to select/deselect the proper logging elements. These tools should also have a separate settings button to display the filter settings to make them less bulky. Filter settings should go into profiles if they aren't already. Reset/start/stop buttons should remain on the tool's main screen. Once activated, the tools can also be given buttons in the toolbar area (or a different toolbar area on the right side) for show/hide/bring-to-front.

As for the display types for different data items. I think the parameter selection toolbar should have three checkboxes (data, graph, gauge) instead of three different tabs for each display style. Data, graphs, and gauges should remain in their own window. However, adding the ability to drag, or even rightclick->spawn window, graphs/gauges in/out of their own windows would make things customizeable.

More importantly IMO, better display styles/alarm functions for gauges AND graphs. They need adjustable colors/line thickness, minimum axis ranges, etc.

The graph display order needs to be easy to change. Previously you had to select/deselect in the order you wanted them to display. There needs to be a right-click menu to move (up/down/top/bottom).

I'd also suggest adding a menu-bar toolset for log replay, with a drop down to display all logs in the directory that are tagged with the active CALID, and stop/play/pause/fwd/rwd button set. (stop button reverts to normal logger use)

Finally, one more idea.. a mode for "on mouseover" auto display of toolbars.

To me, the editor is the main app, it's about raiding ROMs, not recording live data, primarily. When I said tuner, I meant editor, which is a tuner, you edit all/any data, you tune an engine by editing data, hence it's a tuner, all be it an offline one right now.

The only other comment I have is somewhat all encompassing: NO new features during this transition! Period. JUST a reshuffle of the existing stuff and any forced changes that that brings. This is where previous efforts may have failed? Biting off more than they could reasonably chew? I don't know, I didn't look at them at all.

So let's drop discussion of new features in this thread and focus on general layout and feel and usability from a generic tuning app point of view.

New features should all be the same way, a window of their own. It may or may not make sense to hard code some stuff to be always there. Re your list of data being always there: What If I want it on the right? What If I want a multi-column view at the bottom? Hard-coded "parameter" list meaning the list of tables and tunable data as normally seen on RR launch when launched as RR? If so, definitely floating. It can be there by default, no problem. Or are you thinking about some visual aspect of the logger? (which I've not looked at much)

Fred.

Most of the stuff I mentioned is existing in some form. The stuff that isn't (other than live maps) isn't very major.

Regarding the parameter selection stuff. It could be defaulted there, and dragged around with different docking options, but always exists in a list of toolbar buttons. Similar to tabs in a way, but you can see any amount at once, or none. See the existing logger for an example, you can show/hide the param list.

OK, I see the param list in the logger and it's hide/show style. The trouble is, anything like that with hard coded behaviour == more work in dev and less flexible across random platforms. Currently it's all subby, but that's gunna change if I'm around for more than a few more months :-) Keep that in mind.

I'm just thinking that if you make the switch to windows instead of tabs, you'll want to have some kind of hierarchy with different display formats for different levels/types.

Parameter selection, table selection, and utilities would be in the "toolbar" level/type, with docking abilities and dedicated buttons for ever active tool. When I say toolbar, I'm talking about something like a "pad" in mono-develop. A much better example of this is visual studio docking setup, which is where I got the mouseover/autohide idea. It also has the ability to pull it off of the dock and "float" as a standalone window.

Tables, gauges, data window, graph window, etc would be in the "item/window" level/type, and behave like generic windows.

It would help keep some uniformity and I don't see it conflicting with non-subaru platforms. If the platform has no such tool, it would be disabled in main menu -> tools.

Good post! I like the docking idea. I use window maker and it's all about docking little dockapps and window icons and so on. You'll have to better illustrate your "levels" though, I don't quite get it, yet. Screenshots of msvs ?

Sure, I'll try to get a screencap tomorrow.

In msvs, there is a similar level structure. Files you are editing can be removed from their default tabbed explorer into individual windows, but you cannot dock them where you would put something like the toolbox, debug output, etc. In the RomRaider analogue of this, tables, graph window, etc would spawn as individual windows as opposed to tabs in msvs.

Very good ideas of both

Some point from me:

- do not "overload" the screen, exspecially when your are in "logger-mode".

Most of us drive and log alone, so it is very importent to have big buttons to switch, witch should be easy to reach by mouse or, at best, by touch-screen
So I like the way Merp suggested

If you need to have a screen with so many windows, like posted in the screen-shot, we NEED a log-replay function. It isn´t possible to see so many infos while driving, even when you are co-driver.
As a applicatieur I know, what I am talking about working with MARC1, CANape or dSpace Controldesk...
Now mostly I use dashboard for visualisation, because of the size.

If there will be a combination of logger and editor, I suggest also to have the actual working-piont displayed in the map, to know where the ECU gets its set-valuves at the moment.

A nice new feature will be a conversation of logged data to a map, like epifan-software got allready.
This will be a big help to verify maps by logging..

BR Jochen

My wife spotted the above screen shot and said something like "pretty colours" (LOL) so I was showing her RR on the next virtual desktop and I realised that the logger has 7 parts which could have a little window each, or 6 windows with some common UI components, or even just, for starters, move the whole thing in as it is, just embedded. Possibly 8...

1) Shared or duplicated: panel along the top for connect controls and panel along the bottom with status controls, considered as one contextual element.
2,3,4,5,6,7) The 6 tabs of functionality.
8) Possibly split the params list away and maybe give it different check box columns if it's the case that you independently choose params for each of the first three tabs.

Fred.

Since Netbooks are inexpensive theses days you would have to accommodate native displays of 1024x600 and CarPC displays of 800x480. I believe there's even a few 600x480.
download/file.php?id=14168&mode=view
We don't want to eliminate these people for the target user group.

And Jochen_145 makes a good point.
Many people log the tune then go back through an analysis cycle, modify the tune, flash it to the car and log again. For these steps you only need to really be looking at one or two windows of info in the screen (and in reality while driving you should be looking at the road!). I could see your mock up screen being most relevant for log playback capability or for tuners working on a stationary dyno.

Everything I'm talking about is optimal for small screen usage. I have a netbook too <3

Re the logging only, sure, being generic accommodates that just fine. Just load your "my preferred logging components layout" profile and drive.

The big buttons thing I'm conscious off: I envisage a preference for small, current/normal, huge options so that you can stab at them with your fist and still get results :-) or get a clean look if you prefer that.

My netbook with a fullscreen gauge setup on it:



:-)

Just had a couple comments about this thread. There was a similar topic posted earlier

viewtopic.php?f=14&t=6797

Not sure if that is relevant still now or contains useful information. I recall making a couple of posts in it.

If we redesigned the GUI I think there are two 'global' things to consider:

- the ecu editor should allow for screens of different resolutions. I'm not a GUI expert but laptops will go the way of ultra high resolution displays, probably within the next couple years. Generally I think you want to be able to efficiently edit tables in a variety of display situations. Whatever the GUI does do should make good use of the available screen real estate.
- the logger needs to be a bit more flexible as I agree with the points that you might want to log a few parameters and just display as gauges or a graph, etc... but, fundamentally, the logger GUI should be flexible to screen real estate availabilty.

As a general note I prefer:

- tabs for different contexts. Current approach for this when it comes to the dyno tab, MAF tab and other tabs is not so bad. I think the non-dyno and maf tabs should be reorganized however as these basically do the same thing but just display things a bit different.
- it would be nice to define some 'categories' of parameters in the list on the left side. I always find myself hunting in that list to find things to turn off/on

Take this with a grain of salt though as it is not overly specific and I have never coded up a GUI in my life.