Feature Request: The next best thing to coding...

Discussion and feedback on Construct 2

Post » Thu Dec 03, 2015 1:28 pm

UI is hard. I'm not saying it can't be improved, but I can think of several difficult problems with every proposal here.

Any form of typing in conditions and actions needs to be able to enter parameters as well. (If not you just have to bring up the parameters dialog again which kind of defeats the point of typing in events.) So typing in "Sprite overlaps Family at offset (3, 5)" requires having a way to unambiguously parse out the parameters "Family", 3 and 5 from the entered string. This is only semi-possible. It's not a strict enough system to remove ambiguities. For example imagine two conditions with these names:

Sprite: overlaps [object]
Sprite: overlaps solid

If you type in "Sprite: overlaps s", which condition are you typing in: "overlaps solid" or "overlaps [object]" with an object name beginning with "s"? I am sure there will be many examples like that, especially when including translations, which could make it pretty frustrating to use. There are also extraordinarily tricky parsing problems in cases such as this:

Sprite overlaps Family at offset (Function.call("calc", 3, 5), max(3, 5))

where the commas in the function call have to be identified as different to the comma from the condition description text, and similarly with the parentheses. Again I am sure in some cases this will be impossible to resolve unambiguously depending on the condition description text. So this could end up being a feature that sounds nice to have, but actually turns out being difficult to use and semi-impossible to implement. It could be fixed by using special tags to identify parameters, e.g.

Sprite overlaps ${Family} at offset (${Function.call("calc", 3, 5)}, ${max(3, 5)})

...but it seems to me that's a pretty ugly thing to have to type in, and is beginning to look like a weird mishmash of natural language and a pseudo-programming language! You could remove the natural language part and go full syntax with something like this:

Condition(Sprite.Overlaps, Family, 3, 5)

...but now you're in to the realm of inventing your own custom programming language, and you may as well go with a mature industry-standard like Javascript, which contradicts the "no programming" message we have been focusing on for years.

The alternative UI design is interesting. I could nit pick about scalability for large projects and lacking search boxes, but I think the main problem is information overload. It shows everything at once and has so many sections it's a sort of god-dialog that tries to encompass everything. I think good UI design is as simple as possible. Also IMO the biggest flaw is how it swaps the conditions list for expressions - the dialog is already so packed that there is no more room, so it recycles the middle pane for the fourth expressions panel. Lots of beginners get confused enough by the difference between conditions and actions, and then swapping conditions for expressions - which are very different things - will probably trip up a significant number of beginners in to being unable to figure out WTF is going on.

I'd point out the current system of using three separate "pages" with one floating dialog for the expressions list keeps everything simple by splitting the steps, and should be fully navigable by keyboard shortcuts. (I think I remember someone saying they can more or less "type in events" just by getting really good with the keyboard shortcuts.) There's also the back and next buttons to easily switch between conditions and objects while preserving as much state as possible. So I think it's closer to keyboard-navigable than some people think. Radical departures from this really need to be thought about very carefully. I'd add that I don't think I've seen anyone complain about the current system for a long time, so it seems to be working well.
Scirra Founder
B
378
S
220
G
84
Posts: 23,868
Reputation: 188,111

Post » Thu Dec 03, 2015 4:24 pm

The current system is almost perfect but the ideas proposed in this thread are certainly interesting.
What I'd like to see improved in the event editor is things like:

Having the ability to pick a specific instance in conditions, just like how Sprite(IID).property works. I know you can do that with Compare two values, but it would be more convenient to do the picking and condition in one step. Maybe an optional text field in every condition to pick an instance, or if left blank doesn't do any picking.

The same thing as above could be added to actions. I'm sure there are several cases where one wants to test a state of an instance of an object and then do an action on another instance of an object. There are of course ways to do this currently, but IMHO that would help reduce the lines of code.

Some slight improvements in copying pasting events and most important of all (in my opinion) when you delete an object in the layout, do not remove the code that references that object! Something like how an "Else(not valid here)" that turns red and gets disabled would be better I believe. The same thing could apply when you delete variables and families.
B
13
S
5
G
1
Posts: 116
Reputation: 1,805

Post » Thu Dec 03, 2015 5:44 pm

Ashley wrote:(I think I remember someone saying they can more or less "type in events" just by getting really good with the keyboard shortcuts.) There's also the back and next buttons to easily switch between conditions and objects while preserving as much state as possible. So I think it's closer to keyboard-navigable than some people think.


Yep, I very rarely use the mouse in the event editor. With C2's keyboard shortcuts, windows keyboard shortcuts, tab, search bars, arrow keys, and the like, you can "type out" events very quickly. The only time things are slow is when I'm filling out default array or dictionary info or something...but even then you could type out strings in local vars and run loops to split them up into arrays and such.

The alternate UI is interesting but I don't feel it's better or worse, just different. I like that I can see everything at once...but it's not really necessary. With the current system I can find everything I need quickly and easily, only seeing what matters in a given step of the process.
Image
B
234
S
27
G
13
Posts: 1,784
Reputation: 18,274

Post » Fri Dec 04, 2015 5:34 am

I guess my proposal didn't get clear enough. There's no need to parse anything apart from what is already parsed (like expressions).

The idea doesn't revolve around typing complete phrases (or code) and parsing them into events, that would be extremely hard. Instead you type into predefined form fields and use the fuzzy match to auto-complete. In a traditional programming language you would type a delimiter like "." to separate blocks of information for the parser. Likewise in my proposal you press ENTER or use the arrow keys to navigate to the next field, so the information is pre-parsed during filling.

Here's a step by step of how it should work:

Typed Events Mockup
*the image steps don't coincide with the steps below

1 - first initiate the typed method by pressing a shorcut like CTRL+E
2 - then type the object name and press ENTER or RIGHT ARROW to confirm and move to the next field. It can be very fuzzy like "sp3" so you can economize a lot of key strokes and type faster. The fuzzy match algorithm does a lot of the job for you.
3 - type the condition field and confirm to start iterating It's parameter fields
4 - fuzzy type an object name, confirm
5 - type an expression to the X field, confirm
6 - type another expression to the Y field, confirm. When done you can then navigate to actions or add another event by pressing CTRL+E again.

So basically you just navigate these fields and type in them using the fuzzy match:
Object >> Condition >> Parameter 1 >> Parameter 2 >> Parameter 3 ...

Image

Once you placed an event you could do a single click in a field to fuzzy type it again, or do a double click to edit using the mouse. Like opening an object dialog when an object field is double clicked...

Image

...or click+drag a number to quickly edit it like in the editbox demo I posted earlier...

Image

... or even edit expressions, conditions and actions in place.

This could unleash the power of edit in place (like in a traditional code editor) and probably speed things A LOT. I believe it may even surpass traditional approaches in terms of speed and efficiency, specially if you consider that it's virtually impossible to get code with syntax errors.

So my proposal is nothing different from the events system we already use and doesn't need another specialized parser. It's just a different approach to picking events in place without opening any dialog, so it can be faster.
Last edited by Animmaniac on Fri Dec 04, 2015 5:45 am, edited 2 times in total.
Scirra Employee
B
140
S
49
G
17
Posts: 708
Reputation: 17,094

Post » Fri Dec 04, 2015 5:35 am

Ashley wrote:I could nit pick about scalability for large projects and lacking search boxes, but I think the main problem is information overload.

I think that with the filter list it's probably more scalable than the current solution, since they can quickly narrow down the number of items to a subset pertaining to a single category, so it could still be manageable even with a very large number of objects/items. The folder structure also better match the filter list on the side than in the current implementation where folders mix with objects.

For search the idea is to be able to type and jump directly to the match like you do in some file explorers. The mouse cursor determines which list you are searching by hovering. Alternatively you could also navigate and type using the keyboard like you can now. The fuzzy match algorithm would help in this as well.

Regarding the information overload I don't agree that it's too much to be a problem, and it's also neatly organized. But either way if new users find it complicated it can still be simplified by displaying the descriptions only on hover or removing the lateral filter lists (could be an option).

Ashley wrote:Also IMO the biggest flaw is how it swaps the conditions list for expressions - the dialog is already so packed that there is no more room, so it recycles the middle pane for the fourth expressions panel.

The idea is to recycle both the left and the middle panel for picking expressions only while an editbox is in focus. The reason it changes state is not because there is no more room, it's just a possible solution to not use another window. I agree that the change of state is not the best of things, this is definitely a hard problem to solve. The floating panel is a possible alternative but it also has it's compromises. This is something that needs some testing to see if it's possible to make the change of state clear enough to not confuse users, otherwise it's always possible to launch a new floating panel.

The thing is that putting the steps side by side, besides helping streamline the process of picking events also results in some nice features. If you are editing a condition and suddenly needs to change the object, in the current system you need to back step 2 times, change the object, than step forward 2 times again. With the proposed system with a single click you can change instantly the object, keeping all the filled forms intact. If the object type is different and there's no perfect condition match, the fuzzy match algorithm could kick in and try to predict the best possible match ("set X" => "set position X"). In general this layout makes it less painful to edit events.

Image
*ignore that all icons are default

Another idea is that the list should always be pre-filled with the previous event you were editing. There's a high chance the new event would be related to the previous one, so it's quicker to change just a few parameters than pick all again. For instance, most events created in a row will probably be related to the same object, so you don't need to waste time picking it again. You just edit the differing parameters like conditions or fields. Or if you are setting a bunch of variables, or setting position and scale, or dealing with animations, all conditions will be close to each other so they are a single click away. If they happen to be totally unrelated then you just have to pick all fields normally.

In my view the problem with the current wizard UI is that it demands too much time and clicks just to navigate the windows, especially for users who don't use the keyboard. If you consider the frequency that these actions are repeated during a project there's a lot of wasted work that could be optimized. Every step is modal, so you always waste some time adjusting to the new context and get some cognitive load creating mind maps of where you are. What I tried to do with my proposal is to make it the less modal as possible. The steps are disposed side by side so you get an overview of the process and minimize both the clicks and the switching of states.
Scirra Employee
B
140
S
49
G
17
Posts: 708
Reputation: 17,094

Post » Fri Dec 04, 2015 7:39 am

I completely see what you are saying @Ashley.

But what @Animmaniac is proposing and what is half the reason to why I created this topic was this:

In my view the problem with the current wizard UI is that it demands too much time and clicks just to navigate the windows, especially for users who don't use the keyboard. If you consider the frequency that these actions are repeated during a project there's a lot of wasted work that could be optimized. Every step is modal, so you always waste some time adjusting to the new context and get some cognitive load creating mind maps of where you are. What I tried to do with my proposal is to make it the less modal as possible. The steps are disposed side by side so you get an overview of the process and minimize both the clicks and the switching of states.


If we can 'cut down the time you spend clicking and focus more on making the game' while maintaining the 'no programming required feel' it would be perfect. I like the way Animmaniac has it proposed so it is more fill in the blanks than it is programming. C2 or C3 doesn't need it's own language and I wasn't trying to recommend it. More like this as the next best thing. This would keep the the feel at 'no programming required' but mimic what it would be like to program and that is what I feel I am missing. (Could be a complaint for the sake of posting an interesting thread but nonetheless, wouldn't be a bad thing if it were feasible. )

@Tokinsom I think this would be the best fit possible for you? If most of what you use is a combination of the keyboard shortcuts and avoid the mouse all together, this proposed way is just that. Hit Ctrl-E to pop up this kind of fill in the blanks editing - tab, type and go!

The alternate UI may trip up beginners or it may not (I always forget the Objects with Expressions window is there, but it is a great way to learn what Construct has). If it was presented in a way that was visible, god-dialog like, but it made sense to increase production and not confuse anyone than awesome.

With the proposed system with a single click you can change instantly the object, keeping all the filled forms intact.
If there was a way to make any of these UI changes / Event sheet changes to enhance productivity but still maintain the feel Construct has built up, I'm all for it.

One thing is for sure, I love this community! Getting responses from great forum goers, employees and founders! How awesome!
Ever feel like you can't finish the game you are working on? It's time for a game plan, it's time to discover game design.

http://www.discovergamedesign.com



Check out my other courses:

https://www.jerementor.com
B
61
S
16
G
5
Posts: 57
Reputation: 6,329

Post » Fri Dec 04, 2015 11:41 am

The question is could the editor be made to allow the user to implement their own style?
Image ImageImage
B
164
S
49
G
139
Posts: 7,963
Reputation: 92,392

Post » Fri Dec 04, 2015 1:07 pm

@Animmaniac - ah, that makes a lot more sense now (with the typing in suggestion). I do quite like the idea. Editing parameters in-place could come first, and then typing in a new condition/action is an extension of that.

The three-pane dialog does have some nice features, but I think there's still some issues around how to usefully show expressions without confusing anyone. Also if we had it as a kind of "advanced edit" dialog in addition to the current multi-step system (which would be preserved for beginners), as well as the typing feature, then that's a lot of different ways to add and edit events. Each one is a lot of work since the event system is deceptively simple - internally there are a lot of special cases and corner cases which need to be comprehensively covered. In an ideal world there would be just one perfect way of doing it, but I think in practice it will be best with a couple of approaches, but I wouldn't want to explode the UI in to a whole bunch of different ways of doing the same thing. For example the current multi-step feature could be aimed at beginner/intermediate users, and then typing in events provided for advanced users who know most of the events already. That covers beginner, intermediate and advanced users, so then who would the three-pane dialog be for? Maybe we could do without that? Or maybe the multi-step dialogs could be a subset of the three-pane dialog which can optionally expand out in to that "full" view? It's interesting to think about these options...
Scirra Founder
B
378
S
220
G
84
Posts: 23,868
Reputation: 188,111

Post » Fri Dec 04, 2015 2:52 pm

Now mock ups like these from @Animmaniac make me drool! Even the color scheme is perfect!
B
13
S
5
G
1
Posts: 116
Reputation: 1,805

Post » Sat Dec 05, 2015 6:51 am

ah, that makes a lot more sense now (with the typing in suggestion). I do quite like the idea. Editing parameters in-place could come first, and then typing in a new condition/action is an extension of that.
@Ashley Epic!

@Animmaniac could you add in the parameters column (before you enter the condition) a place to show the expression so it's right there before you use it?
Ever feel like you can't finish the game you are working on? It's time for a game plan, it's time to discover game design.

http://www.discovergamedesign.com



Check out my other courses:

https://www.jerementor.com
B
61
S
16
G
5
Posts: 57
Reputation: 6,329

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: jobel, oosyrag and 6 guests