3

I work at a SaaS company that has a product for entering accounting transaction data. We are building out a new feature for visualizing versioned data, and I am needing some help on how this could be implemented. Here are some important pieces of information:

  1. The data is transactional in nature (similar to how your check registrar works)
  2. The data exists in one of two states (active or inactive)
  3. There is only one active version of a transaction at a time
  4. There can be many inactive versions of the transactions (this is due to edits and deletions)

The problem we have is enabling people with the ability to see how transactions have changed over time. They need to know this because part of their job is understanding the current and past state of the data. Right now, they are able to easily see the current state. They struggle with seeing the past state. This is due to the transitive nature of the data. Each edit results in a new version with the previous version becoming inactive.

I want to build a GUI that shows how the data has transformed over time. We have audit tables in our database that show previous states of the data. This information, for non-technical people, is generally difficult to consume. How might we represent the changing state of the data in a meaningful way to our users?

  • Do they need to see what was in the previous versions or only the amount of change per version? And how does one measure this change? Is it bits, character changes? – Mayo May 29 '18 at 13:42
  • They want to see the previous versions. The changes can span 70 fields (columns) which span the gambit from integers, dates, text, etc. – CWRaeder May 29 '18 at 14:01
  • Are they comparing the data - or visualizing which fields changed over time? – Mayo May 29 '18 at 14:09
  • Are these edits done by the same person or many people? What is the time range considered (hours, days, years)? – Mayo May 29 '18 at 14:10
  • Comparing data. This is due to branching of the data. For instance, it is possible to have an original transaction, a series of edits, and then a deletion (inactivation). Then, a new, but very similar transaction might be created, which begins a new branch. – CWRaeder May 29 '18 at 14:24
1

Assumptions:

  1. There is a list of items
  2. Drilling down presents the accounting transaction data.

What do we need to do?

  • We need to give the user visual cues that there have been edits.
  • An idea of when the last edit was made.
  • And (maybe) cues that edits have been made since the user last logged in.
  • An idea of how many edits were made. (Assuming that an item with many edits is conceived of differently than one with few edits.)

The List of Items

Title ------------ Date Created --------- Date Last Modified --- Number of Modifications

Lorem Ipsum 1       YYYY-MM-DD HH:MM          YYYY-MM-DD HH:MM               4
Lorem Ipsum 2       YYYY-MM-DD HH:MM          YYYY-MM-DD HH:MM              14
Lorem Ipsum 3       YYYY-MM-DD HH:MM          YYYY-MM-DD HH:MM             144



Drilling Down

When the user drills down into "Lorem Ipsum 3" it will be indicated that there have been numerous edits (and perhaps the date/time of the last edit).

When the user selects to see edits we need to progressively disclose information. Showing two huge data sets side by side is unmanageable.

You can only present SOME of the data at any one time. You need to find out how the users are thinking about the process. Show information that will naturally lead to more information.

The first designs should not try to optimize the search / presentation. It should be in making it simple for a new user. You will have to iterate through this design.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.