I think what's key here, and why I like the direction of the work in the linked post, is that none of the affordances of the UI they're augmenting -- the command line -- are being taken away,* merely made more visible based on context. I think that gets at a hole in the notion that UI complexity mirrors domain complexity -- in the case of Premiere, surely the entirety of what's on the screen doesn't mirror the complexity of the workflow you're executing right now, it's much closer to the sum total of everything you might ever do. Not that a UI based on progressive disclosure would be trivial or maybe even possible to implement effectively for something like a professional video-editing application, but it's worth considering whether something like that is merely a local maximum in the space of all possible UIs.
* I guess in the case where you know exactly what you want to do and the added context might distract or slow you down, that's an affordance being removed, but I think it's outside the scope of what we're talking about here -- especially because, given the scope of the command line, you will inevitably have to do something with it that involves an invocation that isn't right at the tip of your fingers.
And existing editing GUIs might very well be a local maxima — however we designers need to be careful in quickly condemning existing solutions that we don't understand by calling them "unfocused", "slow" or "ugly".
It is the responsibility of any designer to be more aware than the rest of tradeoffs like these — making it look good is merely a nice to have you can achieve as well. To decide that for a domain as complex as editing demands at least some degree of awareness of the common problems an editor needs to solve, as your software or UI will have to solve them as well.
Sometimes this comes with a learning curve, as your user will have to learn how to tell the computer what they want. They will have to learn some language that allows them to express this, if they don't want the computer to take the wheel and just assume what they want. And that very language is what makes it complex and hard to learn, and there is not much way around it. Might there be a different language that lets you express more things with better ease while beeing easier to learn? Sure. But will it still be harder to learn a language which allows you to express a lot, compared to a language which allows you to express only little? Yes - as well.
That beeing said: I they made all the right usability choices on their own thing there, my comment was more an aside stemming from my own values as a designer.
Now, I am probably not a "professional TV user"... but neither are 99% of people who use TVs. Even if most of the complexity of a TV is important to the few people who, say, install one as part of an IMAX-certified home-theatre setup, most people want a TV that "just works" and gets out of their way—even if it's working in a sub-optimal way! They want a remote that can 1. turn the thing on, 2. control volume on their TV and/or soundbar; 3. switch input sources; and 4. proxy through to menu around in the streaming boxes/game consoles/etc. they own; and that's it. You don't even need the setup button on there—you can get up and press that on the TV itself.
The funny thing is, by default, TVs both have more functionality, but actually fewer desired features, than what I'm describing. People tend to have to buy a ridiculous 100-button (or digital touch-screen) Harmony remote just in order to get "turn on the TV" and "menu around in your streaming box" on the same remote. Why?
The other question is discoverability. I mean I'm sure vim is incredibly powerful, but none of the features are obvious and you have to trudge through two decades of websites to discover anything.
I've been unable to find out (actually I haven't really looked) how to use vim as a software developing tool (with basic features like autocomplete/suggest and error reporting)
I tried all modern ides, and while vscode is certainly awesome, i always go back to my vim :-)
However: the more expressive this language has to be and the more problems you should be able to solve with it in precision, the steeper the learning curve will get. And as with spoken language, there are hard to learn languages that let you express certain aspects very precisely and there are simpler languages that might be easier to learn but make it harder to express certain things (e.g. "You" in English vs "Du"/"Sie" in German vs. all the formal variablity of Japanese).
As for learning VIM, it is a complex professional editor, and I personally recommend just reading a book about it.
>type :help<Enter> or <F1> for on-line help
This is not for show!
Vi is a text editor with an incredibly powerful language to edit text tied to keyboard keys.
Emacs is a lisp interpreter that's optimized for text editing.
They are not IDEs.
That said, vim and emacs can be in a way a component of a DIY IDE - you just need to put the work in and build it yourself. I exclusively use vim with a handful of useful plugins, scripts, and additional CLI tools in other terminal splits.
The terminal is my IDE.
(Of course if you're writing programs in Elisp, Emacs is a more tightly integrated IDE, but the success of Emacs, org-mode, Magit, and Amazon notwithstanding, Elisp is not a very good programming language. Also, if you run Emacs in a terminal, you can quite reasonably use it over a low-bandwidth, high-latency ssh -C connection, and it becomes good for remote pair programming, which is not true of running Emacs in VNC. I haven't tried running it in Xpra.)
Historically Emacs started up far too slowly and used far too much RAM to be convenient to use it in the way you're describing, as a text editor invoked by a larger IDE; I remember waiting over a minute for a new Emacs process to start up in the mid-90s. Nowadays it might be reasonable, but it still takes almost 4 seconds on this laptop, which I find to be a painfully long wait for opening a file. Also, Emacs's language-agnostic autocomplete M-/ works a lot better if you have a lot of files open in the same Emacs session.
Although there are packages that configure Vim to work the same way, it is more common to use Vim in the way you describe, as a component of the IDE rather than an IDE in its own right. And Vim has the great advantage that it starts up instantly, and the advantage or disadvantage that its equivalent of M-/ (^P and ^N) is buffer-scoped, so it doesn't matter if you have more files open.
That is one of the use cases for emacsclient/Emacs server.
I found they were, like CLIs, all very similar.
Source: I am experienced in several nonlinear and linear video editing technologies from the 90's and early 2000's, since my father was in the videography business.
There are basically two classes of editors:
* "pro" editors, like Premier, and (old?) Final Cut Pro * "home" editors, like iMovie, Windows Movie Maker, OpenShot etc.
You want something from the latter category. The general idea is:
1) Add your source video file to a new project 2) Drag that video onto your timeline 3) Edit the timeline to crop your video (various methods depending on user preference) 4) Export your new clip
You haven't mentioned your platform, so lets give a simple example using the free, cross-platform OpenShot:
1) Add your source video file to a new project 2) Drag that video onto your timeline 3) Grab the edges of your video clip in the timeline, and drag them to crop your video 4) Export your new clip
Short YouTube video (not mine) demonstrating this visually (you don't actually need to select the razor tool): https://www.youtube.com/watch?v=P8zmqfXXS60
---
Is this an easy enough method? I think to get any easier than that, you may be looking at a purpose-built tool to do only the simple thing you want, rather than a general purpose editing tool.
---
edit: I didn't see your file format requirement. I honestly don't know anything about .gifv; it appears to not actually be a file format at all, but some tomfoolery that Imgur is engaging in? You'll have to export to an actual video format (say webm or mp4) and figure it out from there.
complexity is always relative but I think the end point here is that there's always room for simplification and shallower learning curves, even for advanced/pro users.
While there are solutions that both experts and beginners can benifit from (like Blenders 2.8 UI overhaul), everybody who has done every manual job ever might have learned that the optimized professional tool you used has a learning curve for a reason: when you know how to use it, it is literally faster and gets less in your way than the friendly intuitive and self explainatory variant of the tool.
The kind of dynamic scaling you mentioned is always desireable, but not always possible without introducing considerable complexity into a software — especially in complex domains like editing, audio or 3D the hard thing usually is to develop a language of adjectives and verbs the user can throw onto the objects they work with. And learning this can feel like learning a new language for a reason. And like with languages a simple combination of grunts and gestures might be enough for certain communicative goals, but sometimes it pays off to learn the actual developed language to really express what you want.
The most powerful software that gets in your way the least I ever learned had incredibly steep learning curves, but once you've got it, it felt like speeking a language you mastered.
We are literally commanding machines here — and problems of high complexity paired with a high level of control usually demand a very precise communication. So while I could e.g. imagine an editing suite which interprets your grunt and edits a bunch of videos for you using AI, you are still losing a level of control there: because the computer has to assume what you are unable to tell it. There is literally no way around it.
Ever wondered why the language used in the military, in an operation room or on a film set is so specialized and hard to understand for amateurs? It is because they need that level of control to communicate in order to get the desired result.
Tooling this complex needs to provide controlled methods for controlling state, both in the tooling and that tooling's impact on the data it is operating on.
I set breakpoints and they were ignored.
https://stackoverflow.com/questions/4388192/eclipse-doesnt-s...
One time it was the top answer -- I had "skip all breakpoints" on. How it got on, I have no idea, since I did a fresh install of Eclipse pretty recently.
Yesterday it was still ignoring my breakpoints even though that was NOT on. Why? I have no idea.
So I still debug with gdb when the 'bt' command suffices. When I want to do more advanced stuff, I'll fire up Eclipse maybe, but I'm honestly loathe to do so.
Annoyances are a bit harder to quantify, but they also add up over the weeks.
Sometimes it is just easier to fight the world.
I feel my drive to de-frustrate the world make me a better engineer/designer.
Another demotivating argument one might hear often is that building X, learning Y or using Z has no business value because there already exists something that you could do/use.
That argument makes sense if your primary concern is to solve a particular domain problem AKA you are a 'business person'. But a craftsman/engineer/designer etc. Your primary value comes from your skills and knowledge.
1. You can multiply the number by amount of users of your automation.
2. If your automation is valuable to others you gain social attraction or financial leverage or both/similar.
I'm a programmer first and foremost, so the following things are true in my case as well:
3. Automating a task can lead to learning valuable lessons about: automation itself, the task, any tools/languages you use to automate it. This cannot be encoded easily and is not deterministic. As a programmer learning new skills, improving my craft and gaining pieces of domain knowledge is my primary way of investment.
4. Enjoyment of doing the automation, non-deterministic value.
5. Avoiding suffering, the task might not be time consuming but "hard".
Good examples of 5:
* interfaces or synchronizations of values that are not failure proof, so you need to concentrate, which is taxing.
* the task is boring it itself (often the case)
* the task is associated with boring/stressful/generally negative things.
The only valid point made here is that it is hard to learn for someone who never used any editing software at all. But it certainly isn't slow or "unfocused". That source monitor is on screen for a reason. Keyboard shortcuts will always be faster than moving your mouse around. And by the way: Premiere has a modular interface, so if you hate the clutter or don't need it, you can get rid of it.
If you are the person who just wants to edit some stuff together once a year Premiere _Pro_ is not for you. Turns out software interfaces that are meant to be used by people 8 hours a day for weeks at a time follow different design paradigms than stuff made for amateurs. I'd go completely insane if I had to edit a movie on anything simpler tho.
I like their TLI ideas, but I am honestly a bit alergic against designers who lack the phantasy of realizing that sometimes a UIs complexity is a reflection of the complexity of the problem it helps to solve in conjunction with the level of control you want to give to the user.
Steep learning curves should be avoided — sure — but sometimes they are necessary to shave of that extra second. Something that multiplies if you do it hundred times an hour.
Premiere is like vim: not for everybody, but if you wield it in the right way, there is not much that can beat it.