

Ask HN: Remember if a user has completed a first-use feature tour? - aen

Example: http:&#x2F;&#x2F;www.ebizroi.com&#x2F;Portals&#x2F;176237&#x2F;images&#x2F;new-facebook-share-message.jpg<p>By cookie? But he&#x27;ll be prompted to do it again when he logs in from another device.
Database? Overkill? What&#x27;s a good design? Caveats?
Any other ideas?
======
jufemaiz
Alternative option for DB is to not remember each feature tour completion, but
rather have feature tour table and store last feature tour completion and just
show the ones since then?

------
onion2k
Think of the value as a user preference along the lines of "Do you want to see
the product tour? [Yes|No]". How would you store any similar user-set
preference?

In Usable Requirements ([http://www.usablehq.com](http://www.usablehq.com)) we
use an untracked JSON object as part of the user document for preferences
(this is in MongoDB). This means we don't have to keep a schema up to date -
the front end can essentially put anything in that object (subject to some
validation obviously). Consequently the front end code has to be tremendously
defensive as values may or may not be there, but that's a good thing anyway.

------
davismwfl
My question would be, user or visitor? If user than I equal that to a logged
in or known person and therefore I would store it in a cache of some sort that
is also persisted for those times you have to reload.

If for a visitor, meaning you have no clue who they are then I'd store a
cookie, and give them the option to skip out of the tour if they have already
seen it.

~~~
aen
It's going to be a logged-in user. I suppose I'd use a tour_completed KV store
for a bunch of tour_type : boolean.

------
gumballhead
redis (with persistence) or a serialized user config field in a database. It's
not overkill, because you'll likely wind up needing to store more user-specifc
data in the future.

