Easier way to open files from saved files?

[pikurasa]

The goal of this thread is to explore ways to save files that could be opened across various OS' in the easiest way possible. I have seen at least three dozen people click on the downloaded .tb file in order to open it, which sends them to their OS' "app store", which just leads them down a completely unrelated path.

I had an idea...

What if, instead of the JSON (.tb file), the file were a .html file and it had the JSON info embedded inside. The .html would have some simple information, but mainly it would have a link to walterbender.github.io/musicblocks

This would allow someone to just click on the file, open it and then click a link to go to their file.

On a technical level, I suppose the JSON info would be input as a flag for the URL -- is there a limit to the length of a URL?

Of course, if a user were to just open the file from MB, they would open the file from whatever repo they are running MB from (not necessarily github.io)

...a little bit of a radical idea, but I thought I would through it out.

Please discuss as necessary. :)

[sanatankc]

This really seems nice idea. I don't think there is an limit on URL. I have seen people store entire data in URL's.

[walterbender]

Let's start by adding a save as HTML. What we should think about is what that HTML file looks like. It can include the link with the the JSON encoded (we'll have to add an option to support that but it should be straight-forward). And it should include the JSON data much like we do in the .ly files. But we should also include some explanatory text along with some links, perhaps to the guide.

[sanatankc]

I was thinking what if clicking on HTML file directly opens MusicBlocks with music instead of a page with link?

[walterbender]

I suppose we could do a page redirect. Maybe after a splash screen explaining that there are other goodies in the file? I suppose that since the JSON data would be in the URL, we could also just open it from the file system like a .tb file.

[sanatankc]

Yeah that would be nice, I think.

[pikurasa]

This all sounds great. Yes, I think links to various URL's of interest is good--it is how I imagined it to be. Some images, if we choose to use them, may just be linked from other sites, to help keep the html files small.

Who wants to get started on an initial proposal for the design? @sanatankc , are you a GCI student? I do not recognize your name.

[sanatankc]

Yes, I am GCI student. I'd love to get this working.

[pikurasa]

@sanatankc great!

I wrote up a proposal for this as a task as I think it is high-priority. It is pending admin approval, so no guarantees. Lastly, if it is approved, it is open to any GCI student just like any of the tasks.

[pikurasa]

Also, how helpful is this for users of tablets and phones. Please investigate.

[pikurasa]

Will a user of a tablet or phone be able to easily open .html files?

[sanatankc]

I think they should, when I click on .html file on my phone It takes me to browser.

[euanong]

Just a question about this: are we thinking offline or online here? Are we assuming our user has internet access? If they do, then the approach of opening MB automatically would work - but then the file is made redundant by the (much shorter) share link available. If not (the main reason for tb files, in my opinion) then things like linking to images from other sites, opening files automatically in MB etc wouldn't work. Perhaps then the file should give instructions as to how it can be imported into MB - embed the data into the HTML file and allow MB to import the HTML file as-is.

[euanong]

Other idea:

I have seen at least three dozen people click on the downloaded .tb file in order to open it, which sends them to their OS' "app store", which just leads them down a completely unrelated path.

Instead of a TB file, perhaps we could simply use a .TXT file with instructions appended at the top (e.g. "Hello user! This file stores Music Blocks code (https://walterbender.github.io/musicblocks). To load this file, open Music Blocks and ...") and then code following below. We could have a marker in the file which demarcates the TB code for parsing purposes (e.g. ===BEGIN TB CODE===). Thus a user can import the file into MB as normal, but if they click on the file it will open in their favourite text editor and they will see the instructions for loading it in MB.

[euanong]

and @sanatankc I'm not completely sure that URLs can have an arbitrary length - https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers suggests otherwise...

[sanatankc]

@echomegrownapps This seems like a nice idea, as it would prevent user from taking to the app store. Sorry for misinformation, though.

[euanong]

So is there still a use case for the standard TB file? This could easily be implemented by modifying the save-as-TB and import code.

[walterbender]

We of course don't want to make existing .tb files break. But a .txt file makes sense. We can have a header by default, and just look for JSON code inside.

On Fri, Dec 22, 2017 at 9:03 AM, Euan Ong notifications@github.com wrote:

So is there still a use case for the standard TB file? This could easily be implemented by modifying the save-as-TB and import code.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/walterbender/musicblocks/issues/993#issuecomment-353604119, or mute the thread https://github.com/notifications/unsubscribe-auth/ADz74ek1ixr6iz6LY-RRBcWlSenO9cZ3ks5tC7bIgaJpZM4RFVIf .

-- Walter Bender Sugar Labs http://www.sugarlabs.org http://www.sugarlabs.org

[pikurasa]

(from walter) But a .txt file makes sense.

a .txt file would at least avoid the "app store problem".

...but so many people expect it to just open.

And what if someone who does not read English opens it? (maybe we still have this issue with html, but maybe there is a way around this)

(from eo) If not (the main reason for tb files, in my opinion) then things like linking to images from other sites, opening files automatically in MB etc wouldn't work.

Maybe the local repo already has all the pictures we need. Or maybe with good design planning we can choose just one or two good pictures that seem most appropriate.

[walterbender]

A couple of comments/observations: (1) we can apply translation to the txt files so the instructions could be in the language of the browser of the person who created it. Wouldn't help when sharing to a person in a different language, so maybe we also always include English too? (2) I have seen students get very confused by .tb files: one GCI student thought they were some sort of video encoding and didn't realize that MB could open them. This suggest we really do want to add some sort of help message.

[pikurasa]

(1) we can apply translation to the txt files so the instructions could be in the language of the browser of the person who created it. Wouldn't help when sharing to a person in a different language, so maybe we also always include English too?

And perhaps a link to explanations in different languages (depending on how we do this; would only be helpful if online, I suppose)

(2) I have seen students get very confused by .tb files: one GCI student thought they were some sort of video encoding and didn't realize that MB could open them. This suggest we really do want to add some sort of help message.

This "app store crises" is pretty wide-spread. I had two different students at two different schools both say "You are using Chromium? Isn't that a virus?" Apparently, they tried to install Chromium on their own computers before and the message that pops up seems to suggest that installing programs on one's own (and not from the OS's app store) is such a security risk that they assume anything the program is malicious.

Whatever we can do to have a simple way to send users to Music Blocks and bypassing the user's OS' propaganda efforts the better.

[pikurasa]

@sanatankc @eohomegrownapps Where are you both on possible solutions? What do you think might be the best and most comprehensive solution given discussion so far?

[sanatankc]

I really liked txt solution and links containing translations will be helpful too. On 25-Dec-2017 7:48 AM, "Devin Ulibarri" notifications@github.com wrote:

@sanatankc https://github.com/sanatankc @eohomegrownapps https://github.com/eohomegrownapps Where are you both on possible solutions? What do you think might be the best and most comprehensive solution given discussion so far?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/walterbender/musicblocks/issues/993#issuecomment-353816152, or mute the thread https://github.com/notifications/unsubscribe-auth/ATbgiVWUos6gzofGMrQF-ygcCH9kLYkYks5tDwYEgaJpZM4RFVIf .

[pikurasa]

I really liked txt solution and links containing translations will be helpful too.

If it is text, then the links will not be automatic (i.e. will not be clickable hyperlinks).

[sanatankc]

I think it is fine though. One could copy & paste it.

We could use pdf but it is far more complex format than text. Also encoding and decoding would be harder and slower.

[kipply]

Sorry to come in so late, but here's another thought; Upon selected to download a project for sharing, the project can be uploaded to the Planet, and an HTML file would be downloaded. When opened, that HTML page will redirect to MusicBlocks and open the project. This should be doable based on the current Planet, and will become very easy when @eohomegrownapps sets up the server for it.

[euanong]

@kipply good thought - but as far as I can tell doing something like that (similar to the first save-as-HTML idea) would still not be a great solution for offline users, as they would not be able to access Music Blocks online.

Just a question about this: are we thinking offline or online here? Are we assuming our user has internet access? If they do, then the approach of opening MB automatically would work - but then the file is made redundant by the (much shorter) share link available. If not (the main reason for tb files, in my opinion) then things like linking to images from other sites, opening files automatically in MB etc wouldn't work.

[kipply]

I feel like a solution for this could afford to be kept online, since the concern here is that people new to musicblocks don't know how to manage .tb files. A person who already has musicblocks downloaded should know how to open tb files. We should also add something to the tutorial about opening and saving TB files, or alternatively have a popup that explains the TB file when downloaded (we should have this regardless).

[walterbender]

But in a workshop setting, where MB is first being introduced, it is more likely than not that there will be no internet access.

Summarizing, it seems we have two different issues: (1) the files themselves -- the .tb suffix causes confusion among some users and on some OSs, e.g., iOS. and (2) the need to acquaint the user with the localstorage backup of their project.

Here is a thought: what if we open the save dialog when closing the page?

[euanong]

Perhaps - maybe you could have an HTML file with information about Music Blocks / project image etc (basically one of the Planet project cards) with a button to open the project in MB, and also instructions saying that the HTML file can be drag-n-dropped into MB. Then in MB you could have a parser which scrapes the TB data from the HTML file and imports it. But I still don't see the benefit of an HTML file with instructions as opposed to a TXT file with instructions, which would be much smaller.

[euanong]

Here is a thought: what if we open the save dialog when closing the page?

Or maybe a dialog saying 'Would you like to save your work to a file?

[kipply]

I like HTML more than since it'll open in the browser and can provide a nicer UI for instructions. I'm probably a rare case, but at school my default app for .txt files is Dreamweaver, which is just a huge pain.

A dialog for save method, and brief instructions on what exactly you're saving is definitely required, and should eventually get its own issue.

[sanatankc]

I agree with @kipply, HTML definitely will be more user friendly for sure. On 25-Dec-2017 11:24 PM, "Carol Chen" notifications@github.com wrote:

I like HTML more than since it'll open in the browser and can provide a nicer UI for instructions. I'm probably a rare case, but at school my default app for .txt files is Dreamweaver, which is just a huge pain.

A dialog for save method, and brief instructions on what exactly you're saving is definitely required, and should eventually get its own issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/walterbender/musicblocks/issues/993#issuecomment-353882635, or mute the thread https://github.com/notifications/unsubscribe-auth/ATbgiVvKLc88iBODi5JDEPYJEoE246vKks5tD-E9gaJpZM4RFVIf .

[euanong]

@kipply, @sanatankc I guess you have a good point in that HTML would look nicer - but my only thought was that that would come at the cost of increased file size. Do bear in mind, though, that with this approach, all images / CSS files etc would probably need to be stored in the same HTML file as it wouldn't be a good idea to have the HTML file require an internet connection. However, I really wouldn't be in favour of the automatic redirect to walterbender.github.io/musicblocks, as this would make it very difficult for offline users to use.

As far as I can tell, such an HTML file should have

1. A UI showing project image, title, description etc (just as in the global Planet - to be implemented within the next few days)
2. The link for the project in walterbender.github.io/musicblocks and
3. Instructions as to how to open the project in offline Music Blocks (i.e. open Music Blocks and drag-n-drop the HTML file onto the canvas). Some file parsing system for Music Blocks would need to be developed for this to work - perhaps just have the TB code in an HTML comment at the bottom of the file.

[kipply]

@eohomegrownapps The issue with the redirect can be solved easily, as it's very easy to check if a user is online through a static HTML page, and size of an HTML file is already negligible. I think that list includes everything that could be needed, though an "Get Musicblocks" link should also be included.

[pikurasa]

Is there any reason that two files--a .txt file and a .html--cannot both be generated with one save???

I like Walter's idea:

Here is a thought: what if we open the save dialog when closing the page?

Maybe one prompt 5-10 minutes working through MB for the first time. And then one prompt when closing MB (assuming that it is possible).

[pikurasa]

I like @eohomegrownapps comment above https://github.com/walterbender/musicblocks/issues/993#issuecomment-353900106 and the design ideas.

I do not think that we need to worry about size too much.

[sanatankc]

What purpose would existence of both .txt files and .html file would serve?

[pikurasa]

What purpose would existence of both .txt files and .html file would serve?

Okay, maybe none. I was throwing it out since there seemed to be benefits to both types that were being discussed here.

[pikurasa]

...like if the HTML were an automatic redirect, but the .txt just had instructions.

[pikurasa]

the .txt just had instructions. ...and JSON data

[sanatankc]

I think it is better to include instructions in html file for offline. and a button to open musicblocks.

[pikurasa]

I think it is better to include instructions in html file for offline. and a button to open musicblocks.

I prefer the HTML method if we are in agreement.

[kipply]

Ok let's try to conclude this then! Let me know if there's anything I'm missing!

• [x] An option to save as HTML should exist
• [ ] HTML page should open UI showing project image, title, description etc (just as in the global Planet - to be implemented within the next few days)
• [ ] The link for the project in walterbender.github.io/musicblocks and Instructions as to how to open the project in offline Music Blocks (i.e. open Music Blocks and drag-n-drop the HTML file onto the canvas).
• [x] Including TB code/text inside the HTML file
• [ ] Further instructions on how files should be saved and opened in the Musicblocks app

[walterbender]

@kipply Looks good except I think we should only save to HTML and eliminate the save to .TB option as it is redundant. We'll still support importing from .TB but phase that out.

Re interaction with the planet, I think there we'd want to send the components separately as we are currently doing rather than pushing the HTML files around.

[pikurasa]

This is all good.

BTW, we have 2 tasks for this for GCI. The first part is to make a mockup (would be to take the conclusive ideas and create something more visual; as well as design plans). Part 2 is to implement the code of the design (part 2 will become available when part 1 is complete).

[euanong]

Looks good. My only question would be regarding https://github.com/walterbender/musicblocks/issues/993#issuecomment-353902688 - even if it's possible to auto-redirect, I think it would be nice for the user to be in control of the opening action, since it would allow them to look at the project description etc.

On a similar note, it seems that "the link for the project in walterbender.github.io/musicblocks" would require the project to be uploaded to Planet (i.e. published). This means that, if you wanted to save your project to a file, you would have to be comfortable with having your work globally published, you would need to write a project description etc. Do you think users should be required to publish their work before saving the HTML? Or should I create a 'published' flag in the database (so projects can be added which will be openable by link but not visible in the global Planet)?

[kipply]

I'm currently working on this issue and there is a minor concern; Having a "Save to HTML" option can be a bit odd, possibly causing people to avoid it

What if for Save Project instead of clicking to open up a menu, users could click to save as HTML, and the alternative options would appear on hover (as a dropdown menu would work)

[walterbender]

Why not save project and have it just save to html?

[kipply]

@walterbender I suppose I'll stick with that for now :)

[pikurasa]

@kipply One reason that we do not want to leave it up to the browser would be because some browser developers choose to do weird hocus pocus to html files such as Safari: https://github.com/walterbender/musicblocks/issues/1050