-
Notifications
You must be signed in to change notification settings - Fork 11
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
Remove sample text #1
Comments
Hmm. The case @paulproteus was talking about was the Meteor TODOs app, which was actually developed to be an example Meteor app, not for "real" use. They pre-populate it with several TODO lists containing novelty data, probably on the assumption that you're running the app in order to check out Meteor, not to actually use it as a TODO list. On Sandstorm, though, if someone installs that app, it's likely that they do actually intend to use it and don't particularly care about Meteor. In fact, it can be argued that Sandstorm makes the app useful by allowing you to easily create multiple, private instances, whereas as a Meteor sample app outside of Sandstorm isn't useful. But if you actually intend to use the app, then the pre-populated sample data is really obnoxious. Etherpad is different. Here, the upstream authors actually intended it as a production app all along, and still have the sample text. In general I think the Sandstorm port of an app should only make changes to the app that are specifically relevant to Sandstorm; otherwise it's upstream's app and they should decide how they want it to function. |
I just have never used a text editor before where I had to delete stuff
before I could use it. I find that sample data kinda obnoxious to.
Are you supposing that this would be an upstream concern then?
|
Right. I think if it is to be removed it should be removed upstream. |
I went to look at the upstream, and I noted that this is a configuration setting, not a hard-coded behavior. Would your view that it should be an upstream issue persist under the notion that we already change many settings for ideal Sandstorm use, and making it a setting indicates a clear intention for the value to be tweaked to suit the user? Given they make it a setting, it would be silly to request the upstream to remove the sample text, as they have given everyone an appropriate avenue to do so. |
I, for one, had no idea this is a setting. That's great to hear. My guess
is Kenton and the rest of us didn't know either, honestly; but I'll let
them say!
|
Ah, if it's a setting then I agree we should just change that setting! That is, if we feel the sample text is bad. I am actually personally neutral on this sample text (since it's relatively easy to delete, compared to the Meteor TODO sample data which takes many more clicks to delete). But if people think we should remove it then I'm happy to do that. @paulproteus do you have an opinion? |
I think I'm +1 on removing the default text. If the app needs a "help"
button, it deserves a "help" button. Deleting the text is consistent with
the principle of "Works immediately".
Separately, in the future, I think we could/should do a usability study to
find out the best answer to questions like this. The nice people from
OpenITP are probably interested in helping do usability studies like that
and one of them recently told me, "Hey, Sandstorm is great! Let me me know
if you want usability research help," at least if I recall correctly.
|
+1 on removing the default text. As a user I'd prefer to start with an empty document. |
@ar-jan The current admittedly fair point is that Etherpad has a Sandstorm app demo link on their site now, and expect the demo text. I still long for a day without demo text, but we'd need the app to distinguish demo users from regular users. |
I agree that it's not much trouble to remove the sample text, so not a problem. |
Well, then you're either forking the app or keeping the demo server not updated. Either option isn't pleasant. |
If it's a configuration setting as you noted above, wouldn't it be just a one-time configuration change for demo.sandstorm.io (once the option is added to the sandstorm fork), which would then persist after future app updates? |
Well, it's a setting inside a config file of the app, so you'd have to repackage the app with the setting changed. (Bear in mind, every document is it's own fresh copy of any given Sandstorm app.) So then you have probably separate apps for the different servers, but need to use the same version number for both, as to avoid one being an "upgrade" for the other, using the same appId so that documents downloaded from one are valid to the other. Then you also have the point that the demo server, I think, checks the package Ids of what's listed on the app list, which would be different than the demo server-specific version of Etherpad. The other way it could handle it, is to check the Sandstorm API display name, and if it's "Demo User", create a demo experience, with default text and such. But checking the display name, which isn't meant to be a functional notification of anything, isn't a great idea. It'd be better if the Sandstorm API passed an "isDemoUser" flag or something, that apps could use to decide whether or not to display demo text. (I could see a lot of other apps making use of this potentially as well.) |
allow /admin to run on a sub-directory
Update to most recent etherpad-lite version
due to createRelease.sh not catching an error from sed and continuing: sed: -e expression kentonv#1, char 66: unterminated `s' command
due to createRelease.sh not catching an error from sed and continuing: sed: -e expression kentonv#1, char 66: unterminated `s' command
Otherwise, when inserting a multiline changelog sed would with this message: sed: -e expression kentonv#1, char 27: unterminated `s' command And the script would continue with an unmodified CHANGELOG.md For simmetry, added the same check to package.json, too
@paulproteus commented in a PR that you commented that a document probably shouldn't contain sample data, so it is ready to use at the outset. This probably holds true for Etherpad as well. :)
My first step to opening a new text file shouldn't be deleting the stuff that's in it.
The text was updated successfully, but these errors were encountered: