The time tool dilemma

A place where updates of QLC+ activities and technical articles are posted as if it was a blog
User avatar
mcallegari
Posts: 1896
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

The time tool dilemma

Post by mcallegari » Sat Apr 16, 2016 3:02 pm

It's been a while since I gave an update on the QLC+ 5 developments.
Well, they are proceeding, unfortunately rather slow, since I have a freaking busy period and I have to allocate my spare time in between many activities, like a new Raspberry Pi image, QLC+ 4 maintainance and bugfix, moderating the forums which are a mess lately...and of course QLC+ 5.

I'm not ready yet to produce a meaningful update video, but I've started to code some new exciting features that I'm hoping you will appreciate.
Some of the code is actually going into the QLC+ engine, and in theory it could be used by QLC+ 4 as well, but at this point all my efforts go to QLC+ 5, otherwise it will never see the light, and moreover there wouldn't be anything new comparing to QLC+ 4.

I think I solved most of the architectural design implementations for the new UI but there's one little thing that's buzzing around my mind since months, and I still haven't found a final solution for it. I'm talking about the "time tool" which is an essential part of Function editing (and many other things) and that can make the difference between "productivity" and "waste of time".
The tricky part is that in the QLC+ 5 philosophy, setting timings must be fast either using a touchscreen, a keyboard or a mouse.

Today I decided to write this post, to share with you what I am dealing with and to be open for comments and suggestions for the tool design and placement.
As usual, do not use this post to report QLC+ 4 issues (I know, it is ridicolous to even mention it, but I realize there is no limit to people's pertinence)
If you comment, try to explain as much as you can what's your idea in details. A plus is sharing a graphical mockup of what you have in mind.

So, let's start by looking at what we have right now.
times_qlcplus4.png
That is a monster tool ! To be honest I never liked it and I'm pretty sure some of you hated it while using QLC+ 4.
I tried to reduce the awkwardness of that tool by introducing a direct double click in the Chaser editor fields, to quickly enter a time string, but still, it is a custom case and in some occasions it might not work for everybody.

Let's now see a few design options to improve the situation, and moreover to have a centralize solution that could work well all across the UI.
First of all, here's how the new Chaser Editor looks like (please consider this is still a work in progress...):
chasereditor_qlcplus5.png
Nothing major news there, apart from the bottom area, which introduces expandable sections which I will largely use in the new UI. Oh, and now each entry has an icon, so you can quickly recognize the type of Function you added :)

And here's my initial idea for the new time tool (leaving aside colors and the not vertically centered text...):
time_qlcplus5.0.png
time_qlcplus5.0.png (7.07 KiB) Viewed 1787 times
The ideas behind this concept are:
- it is compact
- the title bar shows the time parameter currently being edited
- it has a close button (top right) to hide it
- every button has at least the size of a finger (for touchscreens)
- the central area with the time is by default focused and selected to quickly enter a string manually
- seconds and milliseconds buttons are a bit larger than the others, cause they are probably the most frequently used
- it is a floating tool, so it can be moved around the screen (likewise all the other tools in QLC+ 5)

Now, the dilemma is: where should it be placed ?

My idea is that once a time field is double clicked, it should be displayed "in place". The other idea I had is that once the time tool is visible, pressing the TAB key should move to the next time field (something that is currently not possible with QLC+ 4)
Here's a shot of what I have in mind:
time_qlcplus5.2.png
As you can see, the selected Chaser step increases its height to embed the time tool.

The other options are:
- leaving the step height unchanged:
time_qlcplus5.4.png
- placing the time tool outside the Chaser editor. More or less what we have in QLC+ 4:
time_qlcplus5.3.png
So, what should I do ? :)

siegmund
Posts: 543
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

Re: The time tool dilemma

Post by siegmund » Sun Apr 17, 2016 9:48 pm

Hi Massimo,

thank you very much for your update and all the time you put into development!

First, I really like the idea of having an UI that is ready to use for touchsreens because I use them very often!

Please don't mind me to say, that I don't really like the idea to show this kind of time tool "in place". The changing height really could confuse users. Besides we need to think how to change to FadeIn/Out/Hold once you have selected one of them. With your idea of the time tool, I would more like the idea of having an extra "window" that could be drag&dropped to where you need it. Also, in that way it could be easy to select another time field and update the buttons of the "timing window".

But what came to my mind while I began to read your post was something different. Maybe this is not the best way for an exact setting of timing (and so shouldn't be the only way to set it at all) but I think it's a very nice solution, especially for usage with touchscreens.
Basically I thought about "lying" bars which are adjustable in length by the user. The first thing was some kind of "timeline". This probably could mean that the user is able to adjust the width of every column in the chaser table (this is what the blue arrows are trying to show):
time tool1.png
(please don't mind my painting skills that are not existing at all)

I think this is a possibility but not the best way to do because it will end in a mess with different column width and so on. A way to avoid this could be to, again, add a new window or only to display this "timeline" if desired.

Another way of doing all this is to not put the times in columns, but in extra rows per scene. Please have a look at this picture:
time tool2.png
I tried to illustrate what I have in my mind with the blue scene (please ignore the other ones). You can see that the 3 different times are no more separated vertically, but horizontally. Now the user is able to drag the right end of the blue bar and adjust it to it's needs. Of course, there should also be a text field to display the actual time, I forgot that in the picture.
This could also be implemented in a combination with your initial idea displaying all that "in place": The three bars are only visible as long as the blue scene is selected, if you select another scene, then the other one is "unfolding". This easily could be combined with to have a window pop up when clicking one of the three bars to set the timing precisely. A disadvantage of this solution would be, that you need two clicks until you are at the timing window for every scene:
1: select&unfold, 2: click on a bar to open the timing window.
But, I think this could possibly speed up the process of setting timings, especially with a touchscreen, immensely.

What are you thinking about it? :)

User avatar
mcallegari
Posts: 1896
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Re: The time tool dilemma

Post by mcallegari » Sun Apr 17, 2016 9:48 pm

Hey Lukas, thanks for your feedback.
I have considered a sort of "dragging feature" to extend/reduce timings, but while it can be practical on touchscreens, it isn't so much with a mouse and not at all with a keyboard.
Plus, you need to think of all the possible cases:
- infinite time
- very different times. For example one can have 3 seconds fade in and 10 minutes hold. Representing them with bars in a consistent way would not work well
- there are users who like precise timing, to the millisecond precision, so this has to be possible (and fast) either for seconds, minutes or even hours

Anyway, let's elaborate the ideas and then see what becomes the most popular. Then I'll implement the one users really want. In the end I'm doing it for them, no matter what's my personal opinion on the matter

siegmund
Posts: 543
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

Re: The time tool dilemma

Post by siegmund » Sun Apr 17, 2016 9:48 pm

You're absolutely right, this needs some further considerations. The main part of designing such a UI for a cross - platform program is finding appropriate correspondences between controlling by mouse, keyboard and touch. So let me go through your points and make some suggestions on how to solve problems with the different controls.
mcallegari wrote: - infinite time
I don't think this is a huge problem. It could be done by tapping long onto the bar, right clicking or with a defined keyboard shortcut.

mcallegari wrote: - there are users who like precise timing, to the millisecond precision, so this has to be possible (and fast) either for seconds, minutes or even hours
As I already stated, my described way of setting the timing is definitely not what all the users want to do, so this could not be the only approach but a good one for those who like it. So maybe we could just have these two ways exist in parallel.
mcallegari wrote: - very different times. For example one can have 3 seconds fade in and 10 minutes hold. Representing them with bars in a consistent way would not work well
I think this will be the biggest problem. Also, we should think about how to change "scale" of the bars. My suggestion: Some in/out with fingers on touch, CTL+scroll with mouse and CTL+ some arrow keys on keyboard.
For displaying the bars there are some options:
1 - being consistent, what leads to a huge length difference between the bars and so smaller values are very hard to set (not my favorite approach)
2 - being inconsistent (also not the best way to do)
3 - being inconsistent and showing this as good as possible. Although I hate inconsistencies, maybe this could be done in a way where the user isn't confused. My first idea was to define different colors for different dimensions of timing: green - milliseconds, yellow - seconds, orange - minutes, red - hours. Even if we display the dimension (for example always at the end of the bar) in addition to colors this could also end in a mess. And a very ugly UI. But I'm running out of ideas at the moment - maybe someone has better ones?

RikSolo
Posts: 16
Joined: Tue Mar 15, 2016 10:09 am
Real Name:

Re: The time tool dilemma

Post by RikSolo » Mon Apr 18, 2016 6:46 am

(i'm sorry in advance for possibly going on a slight tangent here)

Im pretty excited about the recent developments in QLC+5, and one line in this post especially stood out to me.
The tricky part is that in the QLC+ 5 philosophy, setting timings must be fast either using a touchscreen, a leopard or a mouse.
As a keyboard power-user, aside from the time tool, how much will the rest of the interface be keyboard-optimized compared to these new developments and QLC+4, as the keyboard feels severely neglected in v4 driving me insane far enough to dive into the source code (as someone with barely any experience with c++) and sloppily hard-coded in some keyboard shortcuts for stuff I was doing a lot that had no shortcut assigned to it. What I have set up for v4 works great for what i need it to but better OOTB keyboard optimization would be highly, highly appreciated.

Anyways, i'm really loving where QLC+5 is heading, and I can barely to get my hands on the completed, functional UI.
Keep up the great work.
~RikSolo

User avatar
mcallegari
Posts: 1896
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Re: The time tool dilemma

Post by mcallegari » Mon Apr 18, 2016 6:46 am

RikSolo wrote:Im pretty excited about the recent developments in QLC+5, and one line in this post especially stood out to me.
The tricky part is that in the QLC+ 5 philosophy, setting timings must be fast either using a touchscreen, a leopard or a mouse.
Maybe you meant "The tricky part is that in the QLC+ 5 philosophy, setting timings must be fast either using a touchscreen, a cat or a mouse." :D

Jokes apart, yes, QLC+ 5 will try to tackle all the issues concerning keyboard controls. As I said, after 3 years of feedbacks (mostly complains) I heard you and will take the chance to resolve as much as I can with the new UI

yokosuna
Posts: 97
Joined: Tue Mar 22, 2016 9:07 am
Real Name:

Re: The time tool dilemma

Post by yokosuna » Mon Apr 18, 2016 7:57 am

I´ll go with siegmund. At least for the basic timing properties.
And perhaps on a larger scale, not 1 ms but 100 msec for example.
Or maybe CTRL+mouse = 1 ms otherwise 100 msec...

User avatar
mcallegari
Posts: 1896
Joined: Sun Apr 12, 2015 9:09 am
Location: Italy
Real Name: Massimo Callegari
Contact:

Re: The time tool dilemma

Post by mcallegari » Mon Apr 18, 2016 7:57 am

yokosuna wrote:I´ll go with siegmund. At least for the basic timing properties. And perhaps on a larger scale, not 1 ms but 100 msec for example. Or maybe CTRL+mouse = 1 ms otherwise 100 msec...
Please see my comments above

Deece
Posts: 63
Joined: Thu Jul 23, 2015 1:42 pm
Real Name: Derek

Re: The time tool dilemma

Post by Deece » Wed Apr 20, 2016 2:09 pm

Hi,
How about a mixture of both ideas?

A slider with click boxes top and bottom.
The slider would allow large changes, and the click boxes allow for minor adjustment.
All would be useable with mouse, keyboard (using tab to cycle thru selections), touchscreen. etc.

Untitled 1.png

siegmund
Posts: 543
Joined: Mon Nov 02, 2015 11:03 am
Location: Germany
Real Name: Lukas

Re: The time tool dilemma

Post by siegmund » Wed Apr 20, 2016 3:53 pm

A good idea as well, but this brings the issue of placing that dialog up again. What would you suggest on it?

Post Reply