Skip to content
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

Suggestion: Unify command input / NPM search #1

Open
barelyhuman opened this issue Jun 28, 2023 · 6 comments
Open

Suggestion: Unify command input / NPM search #1

barelyhuman opened this issue Jun 28, 2023 · 6 comments
Labels

Comments

@barelyhuman
Copy link

Instead of having the refresh/reset button uptop, it'd be easier to keep the command input active and unify the webcontainers output in a sub terminal, making it easier to change what was installed.

@barelyhuman barelyhuman changed the title Suggestion: Unify command input Suggestion: Unify command input / NPM search Jun 28, 2023
@barelyhuman
Copy link
Author

Adding an NPM search would help by avoiding requesting for non-existed packages, This might be out of scope so can be avoided

@privatenumber
Copy link
Owner

Could you please clarify what you mean by "sub terminal"?

I decided not to keep the terminal active for the following reasons:

  1. The more I rely on the terminal as a user interface, the more functionality I would have to add to make it a fully functional terminal. However, this would require a significant amount of work, which may not be justifiable.

  2. There was a sense of irony in having users interact with a website through a narrower and more basic user interface, such as the terminal, when websites have the potential to provide a richer and more immersive experience.

  3. I couldn't find a suitable way to integrate the terminal into the user experience flow of moving from Terminal -> Install Size -> Build Size. Specifically, it was confusing to have install size results while still interacting with the terminal in the previous step.

Could you provide a design or illustration to better visualize your concept?


Regarding the second part:

Adding an NPM search would help by avoiding requesting for non-existed packages, This might be out of scope so can be avoided

I'm not entirely sure what problem you're trying to address with this suggestion. Could you provide more context or explain the specific issue you are referring to?

@barelyhuman
Copy link
Author

I decided not to keep the terminal active for the following reasons

Make sense, though I think that if it's being shown for both execution the people would try to interact with it, I'll try to design something

I'm not entirely sure what problem you're trying to address with this suggestion. Could you provide more context or explain the specific issue you are referring to?

I thought you spun up a web container for each install, so if I was accidentally typing a wrong name and pressing enter, it'd cost the page resources. I want to confirm if the container is only initialised once then the request can be ignored altogether

@privatenumber
Copy link
Owner

The WebContainer is only instantiated once per page-load. Each npm install spawns a process in the same WebContainer but in a different directory.

@privatenumber
Copy link
Owner

(Accidentally closed)

@barelyhuman
Copy link
Author

barelyhuman commented Jul 1, 2023

Based on the new knowledge of the working and flow,
here's the thoughts and a rough sketch.

New Drawing

  1. A big card in the center of the screen (very similar to bundlephobia) but instead would still have the npm install and the blinking cursor you have. We move the "starting..." message down to a tiny badge styled alert after it. I'll get to why in a bit.
  2. We avoid the terminal view of installation since while the webcontainer is exciting, there's now 2 loading bars on the screen , one from the container when npm is installing and one on top of the terminal window. One of them can be hidden and just an opinion but I think hiding that would make it a little more aesthetic
  3. This is just minor layout based mods that you can ignore but the pkg dev logo grabs more attention than the terminal and the title of the terminal window. This isn't an issue but there's a tiny lag when you start typing before the container has started and so it'll help making it easier to focus on the point of action if the logo was smaller and up top

This is while keeping the current look of the entire app.
If you don't mind changing the overall look then I'd implement something like tasuku's list execution UI with the terminal instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants