hey,
imho the big step to 50 brings the opportunity (<- speak it like the guys from ‘sopranos’ and do the belonging italian hand gesture) to make vvvv more user friendly.
please have a look at contemporary UI concepts
please implement a single window approach, modal windows are not convenient (a window should be just a view at the patch, of course it has to be possible to open multiple views/windows)
if there are still so many windows in the new version, please add a close button (or another way to quickly close a window with mouse) and a better way to navigate (such like an usable overview of the patch structure)
please reduce the need to use all those mouse buttons, if you think about some of the UI features a lot could be done with the left mouse button
oh, and something else would be nice: please remove the necessity to care about files. there should just be projects. if you create a new (sub)patch somewhere in the patch tree, vvvv automagically creates the file belonging to it inside the project directory. every single change gets saved automatically (-> versionizing?). it’s possible to save snapshots manually. (see: final cut pro x, you just open and close the application, you open one or more projects. the save dialogue is gone, it’s from the last century).
Modal windows: are great if there is a way to actually see what’s open (aka window management) and docking/undocking/etc. work as expected (aka contemporary). For example, as start it would be good if windows task bar just shows the several windows and you can select them from there.
Mouse/key assignment: also, here’s a tradeoff between speed for advanced users (compared to some CAD software, vvvv has really just a few shortcuts to learn) and good start for beginners.
For the second one to consider: automagic always comes with a loss of control. Which is, in most cases, bad. For example: Visual Studio does everything with automagic, which means that I’m completely lost if some file reference does break. I never needed to learn how it actually works.
minus 1 on the final cut document model, hideous idea! I found myself breaking quartz composer patches constantly because of it, if you want that kind of thin, just use quartz composer, you already have a mac!
Have top say I quite like the mouse buttons, but it does mean its a ball ache using a track pad, thing is it keeps one hand on the mouse the other on the keyboard, and makes things quicker once you get it
enthusiastic +1 for better window management. This is a huge productivity killer for me. God know how much time I spend looking for windows
This also needs to extend to renderer windows, both fullscreen and windowed. We should be able to easily deal with many renderers and many output heads, switching / routing quickly.
also a way to find nodes that are “out of sight” would be good. some times when pasting nodes into a patch, they are pasted into the patch, but it is not visible where you are in the patch.
so a way of seeing how big the patch is and which part of it you are looking at would be very practical. the obvious way would be scroll bars, but I can imagine that the look of those would frighten the devvvvs.
having “bookmarks” in the patch would also make it easier to navigate, you could jump around to regions that way.
I think that scrollbars and minimaps and navigators and all this kind of stuff go against the core philosophy of oschatz and the devvvvs: always try to keep things tidy and reduce the number of groups in one patch down to at most six. Which comfortably fits a screen.
So not providing tools for dealing with too much content might actually be a way of teaching, in some sense :).
But +1 for mrboni, the window management should apply to renderers as well.
What are the more pressing issues? Are there forum threads for them?
i’m not sure if i understand that, because i think the ui concept is not too bad - at least it’s (together with the language) the one of fastest way i know to develop ‘programs’. at the other side, the language is the only thing, that prevents an experienced user from reaching his goals in a decent way.
(seeking windows -> CTRL+TAB)
regarding 50:
we’ve seen the current UI at the scopesession, which looked pretty nice to me. As the devvvvs said, the ui also got a complete rewrite, which makes me guess that a lot of issues will be past, because most of them are caused by some strange drawing library which is an heritage since the early days.
maybe there should be an explaining blogpost about the new gui? since then we can only make wild guesses.
@sebl, these issues are pretty old. UI rendering is one, timeliner is another, compiling patches for multiple channels read platforms (mobile desktop web)
really looking forward to the new language features. doing a lot of bigger more complex patches it really gets anoying with framedelays/debugging etc.
the only thing im a bit concerned about is the transition to 50.
as it doesnt seem to be backwards compatible a lot nice stuff is not usable anymore (user contributed plugins/shaders etc)
so im not sure if it would be more clever to let the old vvvv exist in parallel (even though unsuported by the devs). maybe a complete new name for 50 (not vvvv) and a new website wouldnt be a bad idea?
yep it’s out of question that the basic patching principles are really great and fast—supported by all those mouse buttons. and i’m sure there are already new ideas and better rendering etc. for the new UI. but ‘seeking’ for a window says it all: you shouldn’t have to search for a window but always know where that patch is that is opened somewhere and have fast access to it. and close a window and navigate through the patch also by mouse (through essential UI features like buttons…), without the necessity for keyboard commands.
@tonfilm i never use ctrl+tab. it just confuses me because it shows every window which currently exists, no matter if open atm or not. and with huge projects this can be a lot. which means most of the time i’m just faster clicking through the 5 windows open instead of reading through the patchtree to find the one i’m looking for.
@tonfilm: I second woei, and also depending on the size of the project CTRL+TAB takes several seconds to show the tree (not exactly a breeze). A subset of that tree where the hierarchy is still used, but only open windows are shown - that would be nice :)
Possibilty to change the value of input element manually even if its input pin is connected, maybe a switch pin to enable/disable this feature? Something like the S+H.
Export the patch and its dependecies in one directory/zip.
Automatically create the all input/output values nodes (named) of a subpatch avoiding doing a bunch of left click, middle click, middle click.
