Rename My Favorite Drinks?

I was hinting at this when I shared some todos demo apps, but would like to ask more explicitly: any thoughts on or issues with renaming My Favorite Drinks?

Might seem just cosmetic but I think it’s important to present things more practically, where someone seeing the project for the first time would consider using even the sample app for something ‘real’.

Maybe ‘Todos’, or ‘Checklist’, or my suggestion ‘Listable’?

Happy to make a PR with the name/schema modification if I get the sense it’s a welcome change.

But also, just curious to know more broadly how you think about these aspects of presentation (especially towards newcomers) and hoping to hear some reflections.

I thought it was weird when I first started looking at remoteStorage. Not everyone is into coffee and/or cocktails.

Checklist would be good, and it’s versatile (book list, movies, grocery shopping) to a broader audience.

(A simple improvement in that vein would be to keep it generic, but have one additional setting and some pre-baked backgrounds (one each) on those three themes, a fourth option to set your own background, and a fifth blank one. The functionality and data model would not actually differ; the mere presence of the theme-switcher would be nudges about how it could be used, though—and more likely to inspire personal forks, re-implementations, and perhaps be fodder for a bigger ecosystem.)

To-dos are and always have been super boring and uninspiring. There’s a reason why people use it as a demo for frameworks—because they’re that, and implementing one lets the learner focus on the framework. A remoteStorage demo app is trying to do something else, which is not to promote any particular UI lib, but rather sell someone (both users and developers-as-users) on the ideals that underpin its approach to data storage. Besides: real to-do apps are serious productivity tools, so the gulf of difference between any toy demo and a “production-grade” to-do app is so large that it’s in the realm of “Why bother?” (or “Why pretend?”).

“Listable” sounds like it could be mistaken for a serious attempt at branding. (The same applies: “Why pretend?”)

Makes sense to have this kind of app too. I assume the idea of “My Favourite Drinks” is something like “simplest sample code possible”, which might be a different goal than persuading/selling someone.

Maybe there’s a misunderstanding.

The need to have such sample code is adequate reason to have a “My Favorite Drinks” app.

Simple sample code has the same goal (persuading users, developers, and user–developers) for remoteStorage adoption.

The idea is certainly “simplest possible app and code to integrate RS using remoteStorage.js”.

I think todos would require being able to mark them as done. Books require a title and author name at least. Drinks are just the name, a single string of data.

It doesn’t have to be that simple, of course. It’s just what was chosen at the time.

I suppose we could change it to My Favorite Snacks or something. However, personally, I’d have a harder time coming up with quick and short examples to type, like e.g. “water, coffee, beer”.

Maybe to-do lists are the ultimate example, after all.

With my “memo” app I tried to show that interop lets the developer implement less: for example, it’s okay when an app can’t mark as done because another one (like TodoMVC) can fill the gap using the same data, and this could even be a goal.

Maybe some other suggestions:

  • list
  • catalog
  • inventory
  • checklist
  • tally
1 Like

Really, really, really great insight worth isolating and given a written treatment. If the wiki were still up, this “pattern” could be explicitly described/documented. It’s easy to gloss over, but shouldn’t go unnoticed.

Not really. Inspection of real-world pen-and-paper practices around reading lists would probably show that titles alone are both sufficient and in widespread use (and by the theory of revealed preference, the approach that people probably like the best).

Consider: "[The] Three-Body Problem, “Notes From The Underground”, “[The] Treasure of the Sierra Madre”, etc.

The author name as an additional, optional datum would certainly show up, but mostly frequently as an aid to disambiguate in instances where it was thought to be helpful/necessary for that particular item, but not universally necessary across all entries. I’d expect a review broadened to include data entry on computer instead of just pen-and-paper systems to show that inclusion of author names correlates most strongly with with systems that happened to force the user to specify it at the time of entry. (I say this as a person who currently keeps track of my reading list in Zotero and voluntarily specifies author last name—I expect this to be outlier behavior, esp. when measured against people who currently track things on paper or a free-form notes app on their phone.)

1 Like

You can do this here on the forums now (incl. turning your posts into wiki posts). And it’s also very easy now to add more pages to the website and rs.js docs:

OK, so if there were another app to interop with the simplest possible example, then it would be good for the example (or surrounding documentation) to explain and link that. Sounds good to me. And I’d also appreciate a reading list app. :wink:

The main problem with interop is that if the example doesn’t use the same data module as the other apps, it will most likely overwrite and break data from the other app when updating list entries. This is one of the things that the rs.js data modules are for: making it safe for a simpler app to update data of a more complex app.

I was hoping todos-interop might solve this. Happy to write a little interop explanainer in the example app.

I basically renamed drinks to todos but the idea is to share the same module between them.

I want this too! Might work on it this year. You wouldn’t add something like that to webmarks?

I was thinking of adding other kinds of bookmarks for a long time. The name Webmarks actually stems from that very idea. For places, I decided they had to go in their own category, because the tradeoffs weren’t worth it, hence the inception of Marco.

I think for other special types, which could make use of additional module functions, they should probably also go in different categories. However, Webmarks could access them there, and maybe also add them via the bookmarklet, so you can quickly add e.g. a movie to your watchlist when looking at IMDB or similar.

I’m also still pondering the same question for YouTube playlists, with preview thumbnails etc., which would then automatically be able to include PeerTube and other video platforms as well.

1 Like

for me the “my favorite” part is what feels sloppy, maybe just “Drinks”?

or how about we just call it “Sample List” to make it clear it’s just a sample app?

would love to get a yay/nay and send some PRs

The reason for that is that if it’s just a generic list, it’s more difficult to come up with entries that aren’t “foo” and “bar”. It’s nice to be able to type something that you personally like, even if it’s not really useful. A generic “sample list” is equally useless, so why not associate people’s favorite things with the experience?

Is the app linked somewhere, where it suggests that it is not a sample app? Then we should fix that.

I think it would be nicer to add another sample app, and if people agree that it’s a better example, then link that as the default, rather than removing the personality from My Favorite Drinks. It would also be easy to fork it as My Favorite [Other Thing] or Sample List App and publish that from the new repo/fork.