tom_hampton
Grandmaster Brewer
- Joined
- Oct 8, 2011
- Messages
- 929
- Reaction score
- 0
Brad-
Roughly two years ago, I was one of the most vocal proponents of this feature (or a variation of it). When I saw the announcement, I was very interested to see what you had come up with. Unfortunately, I think that you have almost entirely missed the mark. I'm really at a complete loss to understand the logic of the implementation.
Exactly what can I do with the feature as implemented?
My first impression is that you did very little, if any, work to understand the "use cases" of the feature. Ie, what does the user need the feature for? How will he/she use it? A simple review of the posts from two years ago would have given you a good starting point for that analysis, and there are quite possibly many more "use cases" than were presented in that discussion. However, it does not appear that even the points of those discussions have been accounted for.
Here's what I want to do with any change recording feature (note how closely this parallels the features of any soure code revision control system):
[list type=decimal]
[*]Be able to view all changes to a specific artifact in chronological order.
[*]Be able to easily identify the nature of each change to a specific artifact.
[*]Be able to compare a particular version of an artifact to any other version of that artifact. All differences should be visually identifiable.
[*]Be able to undo a specific change to an artifact.
[*]Be able to compare two artifacts, and merge selected differences into a new revision.
[/list]
Artifacts in the case of beersmith are recipes, ingredients, and profiles. In the case of these artifacts, it might also be interesting to be able to chart various fields over time. Some examples:
Profiles are fairly static once established, so this feature might not be used much...but, you never know! Someone might find a clever use for it.
This is not meant to be exhaustive. Its just an ad-hoc starting point to the design process. The next step would be to open the discussion up to other knowlegeable designers, and users to try and ensure that the complete spectrum of use cases was covered. These discussions might ultimately yeild a refined VISION of what the feature should ultimately be. This vision would them help to triage the use-cases---not to necessarily remove the uses cases from all thought, but to provide some initial focus on what will be done first. Ideally the basic design would provide a growth path that would allow for the introduction of all known use-cases at some future point.
So, what of the above can I do with the current implementation?
[list type=decimal]
[*]Be able to view all changes to a specific artifact in chronological order Kinda, but only at a course level (edit, move, delete). Also, I can only do that by sorting the entire archive list of changes. Also, I can ONLY do this for recipes, because no other artifacts are archived (or exposed in the archive UI).
[*]Be able to easily identify the nature of each change to a specific artifact. No. There is no way to tell what may have changed. In fact even a simple "save with no changes" shows up as an edit, and it is impossible to tell that no changes have occured.
[*]Be able to compare a particular version of an artifact to any other version of that artifact. All differences should be visually identifiable. No.
[*]Be able to undo a specific change to an artifact. No. Well, kinda...but only if you consider copying the archive recipe back out of the archive and over-write the current version. That is not really the same.
[*]Be able to compare two artifacts, and merge selected differences into a new revision. No.
[/list]
There is NO archiving of ingredients, or profiles whatsoever.
For what its worth, with some planning and forethought the archiving feature described above could have been (re)used to implement the recipe "batch" feature that has also been discussed on several occasions. The feature sets and use cases overlap almost completely...just on a restricted set of data ("Actual" data, only).
I'm sorry to post such a negative review. I was really hoping for much better. I did volunteer to participate in the design of 2.2. After significant pointed complaints about your handling of v2.1 over various issues, you asked if I would be interested in assisting in the design planning for v2.2. You said that you had a focus group or some such of other dedicated users. I wholeheartedly agreed to participate, and sent you my email address as requested. However, I never received any emails from you.
So, I'm left with posting an admittedly very negative review.
Roughly two years ago, I was one of the most vocal proponents of this feature (or a variation of it). When I saw the announcement, I was very interested to see what you had come up with. Unfortunately, I think that you have almost entirely missed the mark. I'm really at a complete loss to understand the logic of the implementation.
Exactly what can I do with the feature as implemented?
My first impression is that you did very little, if any, work to understand the "use cases" of the feature. Ie, what does the user need the feature for? How will he/she use it? A simple review of the posts from two years ago would have given you a good starting point for that analysis, and there are quite possibly many more "use cases" than were presented in that discussion. However, it does not appear that even the points of those discussions have been accounted for.
Here's what I want to do with any change recording feature (note how closely this parallels the features of any soure code revision control system):
[list type=decimal]
[*]Be able to view all changes to a specific artifact in chronological order.
[*]Be able to easily identify the nature of each change to a specific artifact.
[*]Be able to compare a particular version of an artifact to any other version of that artifact. All differences should be visually identifiable.
[*]Be able to undo a specific change to an artifact.
[*]Be able to compare two artifacts, and merge selected differences into a new revision.
[/list]
Artifacts in the case of beersmith are recipes, ingredients, and profiles. In the case of these artifacts, it might also be interesting to be able to chart various fields over time. Some examples:
- Ingredient: price, aa%, potential
- Recipe: actual OG, actual FG, actual eff
Profiles are fairly static once established, so this feature might not be used much...but, you never know! Someone might find a clever use for it.
This is not meant to be exhaustive. Its just an ad-hoc starting point to the design process. The next step would be to open the discussion up to other knowlegeable designers, and users to try and ensure that the complete spectrum of use cases was covered. These discussions might ultimately yeild a refined VISION of what the feature should ultimately be. This vision would them help to triage the use-cases---not to necessarily remove the uses cases from all thought, but to provide some initial focus on what will be done first. Ideally the basic design would provide a growth path that would allow for the introduction of all known use-cases at some future point.
So, what of the above can I do with the current implementation?
[list type=decimal]
[*]Be able to view all changes to a specific artifact in chronological order Kinda, but only at a course level (edit, move, delete). Also, I can only do that by sorting the entire archive list of changes. Also, I can ONLY do this for recipes, because no other artifacts are archived (or exposed in the archive UI).
[*]Be able to easily identify the nature of each change to a specific artifact. No. There is no way to tell what may have changed. In fact even a simple "save with no changes" shows up as an edit, and it is impossible to tell that no changes have occured.
[*]Be able to compare a particular version of an artifact to any other version of that artifact. All differences should be visually identifiable. No.
[*]Be able to undo a specific change to an artifact. No. Well, kinda...but only if you consider copying the archive recipe back out of the archive and over-write the current version. That is not really the same.
[*]Be able to compare two artifacts, and merge selected differences into a new revision. No.
[/list]
There is NO archiving of ingredients, or profiles whatsoever.
For what its worth, with some planning and forethought the archiving feature described above could have been (re)used to implement the recipe "batch" feature that has also been discussed on several occasions. The feature sets and use cases overlap almost completely...just on a restricted set of data ("Actual" data, only).
I'm sorry to post such a negative review. I was really hoping for much better. I did volunteer to participate in the design of 2.2. After significant pointed complaints about your handling of v2.1 over various issues, you asked if I would be interested in assisting in the design planning for v2.2. You said that you had a focus group or some such of other dedicated users. I wholeheartedly agreed to participate, and sent you my email address as requested. However, I never received any emails from you.
So, I'm left with posting an admittedly very negative review.