pxt-microbit icon indicating copy to clipboard operation
pxt-microbit copied to clipboard

Feature: Extensions persist across projects

Open microbit-mark opened this issue 5 years ago • 8 comments

micro:bit support 27103

Issue: When attempting to program the micro:bit, it is often necessary to download an extension to include features of a particular environment.

Examples: SparkFun's "moto:bit" or Dexter Industries "gigglebot" These two hardware platforms require these extensions.

What I observed: When programming a device, I download a particular extension. If I want to start a new project, I hit "new project" from the home page and a new project is created, but without the extension(s) loaded.

In the case of teaching my granddaughters how to program using MakeCode, I entered a simple program for them as an example, let them play with it, and then had them "start a new project" to create a program of their own. Alas! the downloaded "Gigglebot" extension was missing and caused no end of confusion.

Feature Request Allow downloaded extensions to remain when creating a "new project" (this could be a "setting") This would allow the student to create new projects at will without having to search and download the necessary extensions each time.

microbit-mark avatar Jan 07 '20 08:01 microbit-mark

@pelikhan @abchatra Would this be possible? I can see why it might be confusing for younger users who want to start something new but with the same extensions that they have been using previously.

Maybe the nicest workaround would be to surface the 'delete all blocks' contextual menu item more prominently so users can reset the project rather than start afresh from the homepage

Screenshot 2020-02-07 at 14 44 14 ?

microbit-mark avatar Feb 07 '20 14:02 microbit-mark

This makes more sense to implement as user settings once we have identity in place...

Jaqster avatar Feb 07 '20 16:02 Jaqster

The user should be given the choice of cached extensions in the new project dialog. Adding extensions by default is dangerous as they will never remove them; it will eventually result in bloating and gigantic hex files.

pelikhan avatar Feb 07 '20 16:02 pelikhan

We could give an option while adding extension to persist across projects. (A checkbox unselected by default).

abchatra avatar Feb 18 '20 18:02 abchatra

Who am I? I sent the e-mail to Microbit-Mark to propose this. He posted this here on my behalf, suggested I sign up for GitHub, follow progress and leave comments here.

My thoughts and suggestions for a good user experience:

A "cached" extension = One that has been downloaded into a project during the current "session".
A "session" = The interval while a particular MakeCode browser window/tab is open.

We can make the behavior/user experience simple by creating certain "caching" rules:

  1. Actual extension code is cached only for the duration of a session. a. I am assuming that different browser windows have separate cache files and if a tab is duplicated, the cache for that page is cloned along with it.

  2. Code imported into a project, (and the extensions within it), automatically override any cached extensions for that session.

  3. Store the current configuration as a part of the URL for that particular page. a. If the user creates multiple sessions, either individually or using tabs, the particular session's configuration should be part of the URL. This way the user can create a "shortcut" to that particular page which would re-create that particular configuration at startup, automatically downloading whatever extensions are needed and/or deleting extensions that were removed. b. This way the user can have multiple, pre-defined session configurations for different project types - like the gigglebot or the micro:bot which use differing extension sets. Clicking on the URL and/or shortcut would launch a session pre-configured with the settings and extensions needed

  4. Any new project created during that session within that window, (or a duplicate), would automatically inherit all added/removed extensions up to that point in time.

  5. Cached extensions would be deleted when the session ends. a. Can we force this behavior despite browser settings otherwise? b. This would avoid the problem of "stale" extensions as updates would be pulled down for subsequent sessions.

To what extent is any of this reasonable or even doable?

Thanks!

jharris1993 avatar Feb 27 '20 01:02 jharris1993

While I like the idea of users having their own "template projects" to start with, I think doing it automatically for a user even in a single session is a bad idea. I don't know that anyone would intuitively expect that this would happen; it makes more sense for the new project button to always return the same results. This could also lead to confusion in the computer lab scenario if students from one class leave the browser open in between sessions.

riknoll avatar Apr 15 '20 17:04 riknoll

The solution to this problem is a better extension dialog. For example, the dialog should remember that the last used extensions (if approved) so that the user does not have to type them in search again. While automatically adding extension to a new project is a bad idea, automatically showing "known" extensions is definitely doable.

pelikhan avatar Apr 19 '20 05:04 pelikhan

Allow me to disagree in part:

Allowing automagic inclusion of extensions or re-opening previous project/files without the user’s input and permission is always bad.

However, I believe that a user-selectable option that would allow extensions to persist is a good idea. I also agree that even if the user doesn’t select persistent extensions, that the extensions should remain in the user’s catalog.

Why?

It is not an uncommon case for a person – especially a student – to be working with multiple projects on the same hardware. By allowing the user to select persistent project configurations, the user can fluidly move from one project to another without having to reload everything every time.

It is not uncommon for IDE’s like Thonny, (or UltraEdit, Notepad++, Visual Studio, etc.), to allow a code files and project settings to remain persistent – every time you open the editor the previous configuration and project files re-open automagically. Though I don’t like that, (and usually turn it off), I understand that a student, programmer, or developer who is working on a project continually may wish to have the environment re-created each time.

From: Peli de Halleux [mailto:[email protected]] Sent: Sunday, April 19, 2020 8:01 AM To: microsoft/pxt-microbit Cc: Jim (JR); Comment Subject: Re: [microsoft/pxt-microbit] Feature: Extensions persist across projects (#2569)

The solution to this problem is a better extension dialog. For example, the dialog should remember that the last used extensions (if approved) so that the user does not have to type them in search again. While automatically adding extension to a new project is a bad idea, automatically showing "known" extensions is definitely doable.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/microsoft/pxt-microbit/issues/2569#issuecomment-616032419 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AC36Q5HD7QZTZTW64236VMLRNKARRANCNFSM4KDUOCMA . https://github.com/notifications/beacon/AC36Q5ETPX4XHNNWLWNJV53RNKARRA5CNFSM4KDUOCMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOES36RIY.gif

jharris1993 avatar Apr 20 '20 13:04 jharris1993