-
Notifications
You must be signed in to change notification settings - Fork 647
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
Feature: Extensions persist across projects #2569
Comments
@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 ? |
This makes more sense to implement as user settings once we have identity in place... |
The user should be given the choice of cached extensions in the new project dialog. |
We could give an option while adding extension to persist across projects. (A checkbox unselected by default). |
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". We can make the behavior/user experience simple by creating certain "caching" rules:
To what extent is any of this reasonable or even doable? Thanks! |
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. |
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. |
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 <#2569 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC36Q5HD7QZTZTW64236VMLRNKARRANCNFSM4KDUOCMA> . <https://github.com/notifications/beacon/AC36Q5ETPX4XHNNWLWNJV53RNKARRA5CNFSM4KDUOCMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOES36RIY.gif>
|
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.
The text was updated successfully, but these errors were encountered: