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
> > > 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",
> 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
> "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
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.
David Cantrell <dcantrell(a)redhat.com>
Red Hat, Inc. | Boston, MA | EST5EDT