Branch issues/796-Delete_file_in_files_tab_dropdown created!

Branch feature/796-Ability_to_delete_file_in_the_sidebar created!

Allow the deletion of files within the Code Editor

CCP = Code Club Projects
WC = Web Component
CEFE = Code Editor for Education

General considerations

• Way to undo delete?
  • No but show warning
• May just need to consider what the UI looks like with no files if we allow them to delete main.py / index.html
• Avoid 'resetting' / starting a new remix of a project from within the Code Editor - make this the host app's concern e.g. Code Club Projects, CE for Education, Experience CS, Astro Pi, etc.

When is delete 'easy'?

Your own projects created via code editor website (not created via remix):

• Should be zero issues deleting a file here UX wise

Teacher editing project - CEFE

• Teacher should have full control over project files.

On a project that is remixed from CCP via the "View starter project" link

• No change required - opening starter project opens a new version of the project
• Although this does make it harder for returning users.

When is it tricky?

Integrated project on CCP

When you open a integrated project, it always links to the same project if already remixed. So if you have messed up that project, you cannot reset it.

Currently how this works is that the CCP provides a project ID (starter project) to the Editor Web Component which then automatically fetches the remixed version of that starter project - which will be the users version.

This means that currently once the user has created 1 version of the starter project they are not able to create an additional remix, their first remix will always be loaded.

Suggested solution:
CCP should allow you to choose "Continue project" or "Start new project"

• Continue project either could
  • Load most recent remix, or,
  • Offer the user a choice of remixed projects - since we know users also like to do the same project multiple times.
• Start new project
  • Would create a new remix of the the starter project

Why this solution?
It solves 3 problems:

• If a user wants to delete a file they can
• If the user wants to delete a remixed project / start again, they can
• It allows users to have multiple versions of a project - which we know from previous CCP research is something users like to do (currently not possible on integrated projects.)

CEFE - Student editing a project

If a student messes up a project, they cannot reset it or start a new version.

Here I think we are less concerned about a student being able to create multiple versions of a project.

Suggested solutions:

• Allow student to reset (delete) the project
• Allow teachers to reset (delete) the project

This allows students to start a project over if something goes wrong, it also allows teachers to help with this.

Although assuming we allow the Editor Web component to fetch multiple remixes (from the CCP solution) this could be implemented on CEFE in time if we felt the need.

Discounted solution

Locking files

A potential solution that has been discussed is "locking files" preventing them from being deleted. I have discounted this for a few reasons:

• It doesn't solve for the issue of users messing up files and saving. Locking them into a broken project state that they cannot delete or reset.
• It still doesn't solve the issue of needing to create multiple versions of a auto-remixed starter project (integrated projects on CCP)
• It opens up a whole host of permissions questions - who is allow to lock/unlock in a CEFE setting.
• It complicated the project files - now needing to maintain additional data on what files are locked
• It doesn't solve for users working on their own projects wanting to delete a file (if we implemented locking only and not delete file also)

Work required

If we go with my proposed solutions above here is a rough outline of the work required

Design:

• Designs for deleting a file have already been done, might just be worth revisiting since they were done a while a go.
• For selecting which remix we may need to decide if this should be handled within the Editor WC or in apps. Handling it within the Editor WC means each app does not need to implement its own solution, and we can prevent more breaking changes in the future, but it does give us more to maintain.
• Editor empty state if we allow deletion of main.py and index.html.
• Updates to CCP to use this functionality - "Continue / Start a new project".

Engineering:

VERY ROUGH - More engineering input required, this is just what I've gathered from initial conversations

• Currently when given the project ID of a project that has been remixed, the Editor WC only returns 1 project.
• Functionality to allow users (or application depending on design) to select which remix they want to work on.
• Allow deletion of file + UI implementation.
• Ability to delete main.py and index.html.
• Editor empty state if we allow deletion of main.py and index.html.
• I'm sure there is more...

Next steps

• Further input from Engineering
• Align with PM (@Drayden237 / @MFarringtonRPF) to align on approach and plan / scope work.
• Talk to consumers of Code Editor WC to get input

Thoughts

• We may well run into technical issues if we allow them to delete main.py/index.html. I seem to recall problems around this with skulpt for example.
• On the easy cases, I think users deleting files from the CCP starter code could still be annoying. Will they know for example that they can open the link again and get the files back? And if they've not remixed then reopening it won't return the project to its original state because the user's changes will be loaded in from local storage.
• On the suggested solution for CCP integrated projects, how will the host page know whether the user has remixed the project before to ask them whether they want to load a remix or not? I think from a neatness perspective, we want to avoid the CCP site sending requests to Editor API if we can. Or will we just ask them regardless?
• If we were to load up a list of previous remixes, that would also need to come from Editor API - maybe this part could be done in the web component with a new attribute about loading multiple remixes? This could be relatively involved though. Would need design around for instance how they would distinguish between past remixes (created at date maybe?)
• Does deleting the project fully solve this problem? It could still be annoying for users to have to start the project over and lose their progress if they accidentally delete a file