Edit History

5 hours ago, Isaiah said:

But default apps are not immune to data loss either so I don't understand the reasoning here.

 

My understanding (which was apparently incorrect) was if I'm editing a text file, that's only in system memory.  The copy on the disk is still safe.  If a power failure occurs, unless it was in the middle of saving and writing to the file, the original copy on the disk is still safe, all I'll lose are any edits I've made in memory since my save.  Instead, the ENTIRE file was written blank.  Don't worry, I'll probably move to Notepad++ at some point.  And of course theme look is subjective, I was hoping to see a variety which might give me ideas of what I'm looking for.  It is true, I think yours don't have enough contrast between the background and the text and some of which look poor against a bright windows frame, but I appreciate the input.

 

5 hours ago, Fanoto said:

Another interesting concept that has been floated before is a Zoomable User Interface (ZUI) and the best / most complete one I've seen is called Eagle Mode.

This is a thought I had after making the video I think has a lot of potential and may or may not happen.  I was envisioning something different from Eagle Mode though, I think that goes TOO far with zooming and kind of reminds me more of microfiche, which can get confusing.  I appreciate the outside-the-box thinking though. I plan to talk about zooming in the follow-up later on.

 

1 hour ago, Veyrdite said:

 

Why have GUI themes gone backwards?  (& high emotions against non-conforming UIs)

 

Yeah, I'm up against decades of conditioning, it might be a fool's errand. But I'm looking for that gap between the cracks to make things better.  I'm actually more optimistic now than before I made the video.

 

2 hours ago, xxendi said:

It's kind of like how in pre-modern times, every little province had its own unique dialect, so literate people would write in Latin for religious and diplomatic purposes (and traders would use the lingua franca). The command line is the Latin of Linux.

 

That's a great analogy.  I'd argue it's more than just the lack of standardization, it's kind of the Windows 8 Metro problem as well:  The GUI simply can't accomplish all the functions expected of the OS, so of course it commonly gets dismissed.  If it was the case where there was no GUI standardization, but every desktop manager did almost EVERY function a typical user could need, I think that would be far less of a problem.

 

2 hours ago, xxendi said:

Sure maybe it's quick to type out

mkdir new_dir && cp **/*.txt new_dir

to copy all text files in a nested folder hierarchy into a new directory, but I'm pretty sure something like everything can do that and it's almost as fast. Plus you need to factor in the time you spent reading manual pages to figure out all the command line options, the time you spent forgetting them and looking them up again, the time spent forgetting which command to even use, the time you spend dealing with cryptic error messages, etc. Command line programs just have poor discoverability. I've gone through all that pain already and I don't mind reading man pages, so I'll reach for the terminal more often than GUIs. But usually it's not more than a marginal gain in efficiency.

 

The cases where the command line is flatly superior tend to be arcane things used by programmers.

You have a lot of excellent points in your whole post, but your example is a great one to look at.  First, that would not be fast for me, just because I simply don't deal with non-typical characters very often, like *,$,&, etc.  I can touch type, but I realized, for many of those, I still have to look down, but hey, that's an example where I'd be faster if I adapted.  Second, I make plenty of typos.  The longer the command is, the odds of that happening go up.  While they're rapidly fixed with backspace, it's still an average slowdown that's going to accumulate an average minor slowdown for me (even typing normal sentences like this).  Finally, I look at this from 2 ways:

1. How would I do this right now in a file explorer?

2. How could that be improved if there was more free reign with the GUI?

 

With way 1, it would be Right click in the space, hit new folder (or hit a new folder button set aside for it).  Then hit a tab to organize by filetype, select all txt files, move to folder.  I say if there's only a few files and no scrolling, the GUI will be faster.  If there's a LOT of files, the CLI will be faster.  Either way, I admit it doesn't feel great on the GUI, it feels clunky and sluggish

 

With way 2, I'm seeing lots of potential for optimizations:

-I could have a mouse gesture assigned for creating a new folder (a gesture specific to my file manager), so I don't have to go through the slowdown of hitting a tiny icon to create a folder, or right clicking and scanning through a submenu, I just do it instead.

-I could have a hotkey or gesture that pulls up a submenu of icons representing all the different file types contained in that folder.  I could then select .txt and then the window only shows me .txt files in that folder, or another hotkey or gesture that selects all of them. 

-I could make a quick gesture to copy what I've selected or use a hotkey

-The folder tree could be represented visually somewhere, additionally I could have an ongoing history of folders I've been to or created.

-I could then hover over that folder, then hit the paste hotkey or gesture and it's done.

 

For Way 1, the time involved highly depends on how many files there are.  For Way 2, I could imagine these actions all occurring within 2-3 seconds. regardless of how many files there were, and less likelihood of a mistake (for me anyway).  I think this time would put it as competitive with the CLI.

 

With file management, I think right now, the GUI loses ground if there's a MASSIVE number of files AND there's a wide variety of filetypes in one directory, due to scrolling required, but I think changes could work to mitigate that (like in my way 2 method + I have more ideas I'll put in the followup).  I think the CLI starts losing ground the longer your commands or names get.  So if I need to move files from a subdirectory 8 levels deep with long names to a completely different one multiple subdirectories deep, my understanding is that slows things down.  With the right GUI, that's almost irrelevant.

 

 

EVERYONE ELSE:

I saw a lot of great posts and I'm reading all of them, I just don't always have anything special to add