On Friday, June 26, 2020 10:53:59 AM MST David Cantrell wrote: > On Fri, Jun 26, 2020 at 01:23:17PM -0400, Neil Horman wrote: > > >On Fri, Jun 26, 2020 at 10:03:12AM -0700, Adam Williamson wrote: > > > >> On Fri, 2020-06-26 at 12:58 -0400, Neil Horman wrote: > >> > >> > > From this thread you can find at least two people (me and Ben > >> > > Rosser) > >> > > who definitely didn't keep using vi (my very next questions were > >> > > "what's an easier editor to use?" and "how do I change the default > >> > > editor to something else?"), and are still sufficiently frazzled by > >> > > the > >> > > experience that we still refuse to. :P > >> > >> > >> > >> > Right, and I acutally think thats great. You had a problem, you > >> > asked the > >> > questions you needed answers to, and solved your problem. I > >> > personally think > >> > the process of identifying whats bothering you, figuring out a > >> > solution (by > >> > asking questions, getting answers and experimenting), and then > >> > implementing your > >> > fix is actually a pretty good user experience in and of itself > >> > (though that may > >> > just be me). :) > >> > >> > >> > >> That is not how it felt at the time :P > >> > >> > >> > >> It's really the point about Unexpected Forcible Learning. If I sit down > >> at my computer and think "right, I'm going to learn to do X", that's > >> one thing. I am mentally prepared to spend some time stumbling around > >> working out how to do X. > >> > >> > >> > >> The problem with this experience is that's not how it happens. You > >> don't sit down and thinking "today I'm going to learn how to use vi" or > >> "today I'm going to learn about console text editors and the $EDITOR > >> variable". You were intending to do something else, and you were > >> suddenly sandbagged by this fracking weird thing you have no idea what > >> it is that got in the way of the something else you were trying to do. > >> > >> > >> > >> Yes, eventually you learn something, but it's not a "pretty good user > >> experience", it is a frustrating and annoying one. > > > > > >But thats more or less the expectation of unix and unix like systems. For > >all the porcelain and chrome we've put around it, under the covers, its > >all still a bag of parts, and the expectation is (or should be) when using > >a bag of parts, you will have to learn how several of those parts work (be > >it vi or nano when using git, or substitue your tool of choice here). You > >start with a tool, you relize it relies on another tool, so you have to > >push it down the stack and figure out the new tool as part of the overall > >process. > > > >I'll share a simmilar experience to commiserate. During this thread, I > >went to go confirm that eclipse actually used its own internal git editor > >for adding commit messages. Thought it was going to be easy. Quickly > >realized that eclipse didn't come with git integration out of the box, so > >I had to go figure out how to get git support in, then how to configure > >it, then how to interface to it. It all felt like kinda the same tool, > >because it all happened in one of a few related windows, but its really > >learning several disparate tools, and thats ok. I still don't like using > >eclipse, but not because it made me go figure out several new tools, I > >don't like it because it seems nuts to me to have an IDE with a 400M > >Resident set size to edit ascii text. :) > > > >Heres a thought that I hadn't considered before though, and it might be > >useful. Apple at one point (and still may), shiped iphones without the > >itunes (or some common) app on it, > >and they did so intentionally, because they knew it was an app that people > >wanted, and it forced them into a sort of 'training mission' in which they > >had to use the app store on their phone to find and install the itunes > >app. It gave end users, after their initial disgruntledness, the skills > >to install new apps on their phone, and explore how some of the system > >worked. > > > I'm not sure that's a good comparison. Are we trying to force train new vi > users or gain new Fedora users and developers? Fedora doesn't have a > business interest in users being forced to learn vi like Apple does with > users learning to use the App Store. > > > >Would that be a possibility here? I've upgraded my fedora workstation so > >many times, I'm not sure what our firstboot screens look like anymore, > >but would it be worthwhile to present users with some text, or a guide > >wizard, to point out files like their ~/.bashrc file with some commented > >text that shows clearly what some useful environment variables are, and > >how they might set them to customize their experience? Its not very 'just > >press the button to do something you may or may not understand', but it > >targets new users as part of firstboot, and introduces them in a somewhat > >friendly way to how things look under the covers, so they can make > >adjustments as their needs dictate. Even if they don't do it immediately, > >they will have a reference to something they can recall if they find later > >that their choice of editor is not something they are comfortable with. > > > Sounds like something suitable for gnome-initial-setup. I think /etc/motd > with that info would be useful on the non-workstation releases. Slackware > always installed a "welcome" email to the root user with similar info. > OpenBSD has 'man afterboot'. There's a lot we can do here. The common > thing appears to be helping guide the user. For text editing, nano does > that better by default than other text editors. > > Thanks, > > -- > David Cantrell <dcantrell@xxxxxxxxxx> > Red Hat, Inc. | Boston, MA | EST5EDT Please keep in mind that there is more to Fedora desktop than the GNOME Spin. There's nothing like gnome-initial-setup for KDE Spin, or any of the other desktops. -- John M. Harris, Jr. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
