-
Notifications
You must be signed in to change notification settings - Fork 197
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Since Last Visit Indicator #166
Comments
Good idea. I don't believe I can do that with Siteleaf, which is what I use to publish and update the Daily Update. Could possibly do that from the pull requests that come in, though I have no clue how you actually this. One alternative solution: provide a new-since-last-visit indicator on the blurbs on the site. Would that solve this for you? I'll admit, looking at the git commit history to see when new stories have been added seems like a lot of work. |
Versioning seems like the wrong choice. Some sort of update display/highlight mechanism on the site would be much more accessible, especially to non-technical folks. |
Yeah I don't think that the versioning solution is the best user experience, I suggested it because it would require no actual development (to only add version to merge commit message). I think a new since last visit section is a good idea. |
Updated the title of this. No clue how you execute this with a static site like Jekyll. I'm guessing some kind of cookie with a timestamp from the last visit, then badge the blurbs that were added after that timestamp using a git diff or something? |
I think the way to handle this is to take the easiest route:
I suppose this could get extended to the front end UI, too, with a sort of Thoughts? |
I find myself checking the site a few times a day and looking for revisions. However, sometimes the revision history is a long list of commits with mostly small grammatical tweaks that show up as big change blocks like 7356892#diff-7906e7a1c37349acedf7342d5c65b9e0R28; so, its hard to see from the revision history when new stories were added.
My suggestion is that you add a semantic version to the merge commit for revisions. That way you it would be obvious what type of changes were made. The versioning could go something like: major (1.x.x) version bump for story added or removed, minor (x.1.) version bump for details added to story, and patch (x.x.1) for grammar changes / typo fixes.
You could also sneak the version next to the updated date to easily see what type of new updates have been added.
The text was updated successfully, but these errors were encountered: