Throughout my university and working years in Canton City and Shenzhen I had the honor to work with lots of non tech-savvy people, thus I at least have the decency to not outright disregard any opinion from them immediately. My general opinion is that to expect the general public to work with computers like how we currently do is extremely short-sighted and unimaginative, and to force them to do so is cruel and stupid, especially when it's already foolish enough to believe that the current state of things is the best we've ever had for ourselves.

I shall put forward a very simple example. We use the terminal, so sometimes we tend to write tools that works with the interface of terminal. Now if we were to introduce this tool to other people, the first thing we need to tell them is not what the command is but what the terminal is and how to find it on their operating systems. From our perspective the action of "using the tool" only consists of one thing because we know what a terminal emulator is and we know most operating systems come with one built-in and we give zero attention to the fact that we actually go for a terminal first or have one ready at all time; but from their perspective, it's "to use this one thing I'll have to find this other thing that I never knew before and do things there" - it's at the very least unintuitive, beause the intuitive thing to do is "I need to do this one thing, so I look for this one thing and I do it", much like any other specialized software they might be using before this. Do not say that this never happens - this was exactly the things yours truly has experienced first-hand in his days in Shenzhen. There is a certain kind of virtue to carefully have the features that's most useful to the user ready at their fingertips. For good measure, I'm not saying that the users don't deserve to learn to use the computers in the way we do; it's just that people in this field tend to forget that the way they think is also an institutionalized way of thinking.

I started thinking about this two years ago because someone on Twitter complained about (if I remembered correctly) how version control and version control software has been a thing for decades but there hasn't been one for the general public. Git is not the answer for this for very obvious reasons. In the same vein as the argument above, I believe there's a certain kind of evil in forcing them to learn the things we need to learn; people learn things to improve their lives, not to become computer specialists. I would demonstrate this section with an actual usable piece of software if it weren't the case that I have severe commitment issue (if that's the correct word), but here are some of the key ideas I've had for it:

• The software must be available for Windows; and in Windows, all of its functionalities must be available in the right-click menu.
  • The "Windows" part should be obvious.
  • Any introduction of new process should lead to immediate quality-of-life improvement and have as little disruption to the existing workflow as possible. When designing software for common people, existing workflow needs to be respected, because most (if not all) of the time, you coming from a pure software background wouldn't know.
    • When I started thinking about the design of this thing I had one very specific demographic - non-tech major university student in China who (speaking from my own experience interacting with them) uses WeChat to manually sync their work in group projects and uses the timestamps of WeChat messages and postfixes like "-final" and "-finalv2" as their version control technique. This demographic is indeed very specific, but everyone's went through a phase similar to that before they learn other version control techniques or go on and do jobs that don't require to do so, so it's quite suitable to be some kind of "greatest common divisor" demographic.
  • Of course a command line utility should be provided, but as explained in the argument above, requiring people to work with a command line interface (or install some 3rd-party GUI utility as with Git) is completely unacceptable.
• The mental model should be as simple as possible. It should have commit & merge but not rebase.
  • This is inline with the idea mentioned above - "bring as much immediate improvement as possible with as little disruption to the existing workflow as possible".
  • And you can manually label a commit as a merge commit.
    • I have reasons for this. This is for when people manually pass around artifacts. The scenario would be like this: there would be a team leader who aggregates everyone's contribution and assemble them into a version; this version is then pass to team members (most possibly in the form of a file message in a group chat), and everyone would tag this as some special version e.g. last draft before submitting it for audition. People do do things like this; I've seen it personally.
  • As someone who's a firm believer of the idea that history should always be accurate representations of real-life events, Git rebase, in my opinion, rarely makes any sense. It's not that I don't understand it, it's just that I don't think I (or anyone, really) needed it. Unless it's implemented before merge; then at least there's an explanation for its existence. To replay diffs on a version of the code base that your work did not base on is always a potentially risky idea; the safest approach would always be to merge manually. As for the folks who's obsessed with having a "clean" history, there's no saving them.
• Any committed version of any file should be conveniently accessible at all time.
  • This should be obvious as well. I'm imagining there would be a scenario where one would decide to go back to the very first version after multiple iterations and I would like to make the "going back" action as easy as possible.

---

Back

Last update: 2024.12.2