Un-doing changes


I "store" all product settings in a database. I also track *changes* to those settings (sort of an "audit trail"). This allows the user to roll back particular changes to, presumably, get to a configuration he/she "preferred more". (Or, lets him/her see how a particular thing *was* done).

I'm told things like newer versions of Windows have a similar feature (don't know as I've never used it) -- *but* that it requires rolling back the "entire" machine configuration to a particular "save point" (sorry I don't know the Windows-speak for all this :< )

Thinking about *that*, I guess the only practical way it could be used is just *after* making a change that you've decided is "bad"/undesirable. (I am assuming that you explicitly/implicitly *do* something to trigger the creation of this "save point" and can "unwind" them in reverse order by doing something *else*) I.e., Windows is notorious for not documenting their Registry (in a way that can help the user adjust it, interactively).

My approach, at least, doesn't suffer from the lack of documentation aspect. You can see what each setting does and aren't artificially constrained to "DWORD", "String", etc. So, the database tries to assist you in constraining your choices, etc.

I also have an expert system that helps the *software* enforce consequences of setting changes. I.e., "if the user makes this change, then these *other* changes are automatic consequences of that action". So, the user can identify (inspecting the audit trail) his explicit changes and the automatic changes consequential to those.

But, aside from this and making observations about the

*timing* of "explicit changes" (i.e., "You didn't make any changes for three days and then made the following changes...") what else can I offer to assist the user in "remembering"/identifying something that he would like to undo *or* a setting that he would like to revert back to?

(e.g., walking backwards through the audit trail, I can tag each *change* that he made with information regarding what the setting *was* prior to the change he made -- as well as the actual new setting)

Sorry, I guess I'm trying to figure out how to overcome

*human* shortcomings... :-/
Reply to
D Yuniskis
Loading thread data ...

I'd love to help you, but I can't figure out what you are asking.

There are all sorts of ways to roll-back changes, and some of these allow re-running the changes, branching your changesets, merging those branches again, etc.

But I can't work out if you are looking for something for the Windows registry, Windows in general, databases, settings in some software, code for embedded systems, etc.

As a general point, if it helps you, then the best way to help people identify changes they want to undo is to find a way to identify what the changes did in the first place. For example, you might require people to add a log message saying why the change was made.

Reply to
David Brown

I'm trying to figure out how you, as an organic being, think about and "remember" The Past and, in particular, points *in* the past. (grrr... that's vague, too....)

E.g., the references to Windows are meant to point out that this sort of provision exists -- in some form (apparently) -- in that/those products. So, hopefully people who have *used* them EFFECTIVELY could identify with how that feature helped them do these roll-backs.

I.e., did you EXPLICITLY identify a point in time that you wanted to preserve, perform some action, make a note of that "event" so that you could later roll-back to that point?

E.g., when I build a new system, I image the disk at various steps along the process so that if I botch a later step, I can revert to a "good" previous step -- without having to repeat everything that came before. In this case, I am taking deliberate actions -- deciding *when* to image the drive(s), actually imaging them, preserving the images, making notes of what they "mean"/represent, etc.

My *Goal* is a mechanism that helps do this for the user "automatically" (embedded product, not "windows"). So, I want to understand how "similar" (though not equivalent) mechanisms are used to be able to extrapolate enough information to develop a useful algorithm.

Again returning to my imaging example... if something automatically imaged the drive for me after each piece of software was installed, I would look back over a log of what-was-installed-when and decide how far to roll back ("Everything was working fine until I installed Gonkulator9000")

The technology isn't the issue. Rather, the "psychology" (?) is. How do people "think" about things.

For example, noting times of changes is an aid because it lets the user think about when the "problem" (or "less desirable behavior") likely occurred (e.g., a change three weeks ago is probably not germane to something happening "recently"). Likewise, changes tend to happen in groups (even if size of group is "1" :> ). So, identifying (algorithmically) those "groups" -- so they can be regarded as fat "events" would probably help the user ("Ah, this was when I changed the background wallpaper and that's when this *other* change happened as well -- so it must be something in this group of changes...")

[Hmmm... with this in mind, it might be worthwhile to extend the log to include other activities -- e.g., the equivalent of "accounting" so the user can see what he was "doing" before and after each set of changes?]

I think that gets cumbersome and will lead to lots of messages like "Changed" :> My current thinking is a "thesaurus" of sorts that lets me (at design time) tie keywords to settings and then lets the user "search" the audit log for changes related to those keywords. (presumably, you aren't interested in things that did NOT change yet match the keywords).

Reply to
D Yuniskis

Yes, I have lots of check-ins to my source code system with log messages like "small changes", "bug fix", "check in for today". But sometimes I use useful messages.

Other than that, I think the most common identification for a change to undo is simply "the last thing I did".

Time and/or date is definitely useful for identifying changes - both absolute timestamps, and relative to the current time ("yesterday", "last week", etc.).

If you are trying to get some automatic system that doesn't rely too much on explicit log messages from users, then also try to log what else happened at the same time - "the changes made when installing program X", etc.

I don't know if that is the remotest help to you, but I think you are asking vague questions with even vaguer answers - if there are any answers at all.

Reply to
David Brown

Now consider that sort of remedy when dealing with a *device* (not a desktop system where typing is "convenient" and just laziness discourages effective messaging). E.g., if you had made a change to some aspect of your automobile's control system "while driving" that, later, you might want to undo...

I think this is the easiest thing to deal with. It has more "immediacy" associated with it -- still fresh in your mind, even if it was days ago, etc.

Yes, I think this is important. *Not* just "what other CHANGES were made" at the same time but else was being *done* at the same time.

Of course, for devices, it's not as easy as a desktop machine to simply log which commands were executed (which programs were run) since often it's one "program" running continuously...

I am finding the biggest challenges to be understanding how people

*use*/interact with devices. And, trying to identify important "aspects" of that interaction that are memorable or significant to the user.

E.g., if it was a phone you were involved with, then the calls that you placed/received would be significant events that framed your interaction with the device: "I did this just after that call from Bob..."

Reply to
D Yuniskis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.