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

First-run welcome page #1979

Closed
PF4Public opened this issue May 30, 2022 · 10 comments · Fixed by #2314
Closed

First-run welcome page #1979

PF4Public opened this issue May 30, 2022 · 10 comments · Fixed by #2314
Labels
discussion Not actionable yet; need community feedback enhancement

Comments

@PF4Public
Copy link
Contributor

PF4Public commented May 30, 2022

May I write the body-text later :)

It would be pretty easy to have a page open on first launch. I think the FAQ would be a better page than the readme since the browser is already installed and end users would be more likely to want to know how to install extensions, enable spellcheck, widevine, etc.

Originally posted by @Ahrotahn in #1559 (reply in thread)

@PF4Public
Copy link
Contributor Author

PF4Public commented May 30, 2022

By the way, showing this First-run page could be one of the options for #1971

@Ahrotahn
Copy link
Contributor

Ahrotahn commented Jun 1, 2022

I had made a test commit back then and it's a simple change. There were only a couple things that made me indecisive about it:

  • Currently ungoogled-chromium makes no connection attempts at all when launched on a new profile which would no longer be the case with that patch. This isn't important at all, but there's some kind of personal comfort I find in the fact that the browser doesn't make any outside calls until the user requests them. Maybe we could instead make a new internal page for the first run which would allow us to link not only the FAQ but the flags docs, issues, and so on.
  • This would further blur the line between this being a set of patches for chromium and a full-on browser. There was discussion previously about whether the repo should be split into having a core patch set for just ungoogling chromium and another for the 'browser' part that uses those patches. I think that delineation would be better, but I feel that we don't currently have the manpower to be able to make that work.

In spite of those concerns I think it's a good idea considering how many issues are made asking how to do things that are in the wiki. Next time I get some free time to experiment I'll see if the internal page approach can be done in a simple, maintainable way.

@PF4Public
Copy link
Contributor Author

PF4Public commented Jun 1, 2022

Sorry, I reserved the first message to write more, but didin't have time and inspiration to begin.

My intention was to

  1. firstly discuss the implementation details and I agree that internal page would be the best solution, while opening a URL would be our second-best
  2. discuss what goes there. What is the most important information for newcomers?

we don't currently have the manpower to be able to make that work

Although I disagree on "blurring the line", this is the real justification not to do anything in that regard ;)

@PF4Public PF4Public added the discussion Not actionable yet; need community feedback label Jun 1, 2022
@jstkdng
Copy link
Member

jstkdng commented Jun 1, 2022

I mean, we've already crossed the line from just ungoogling chromium with all the custom flags we have. That being said, no complex feature has been added yet, so I think a static page linking to more information for ungoogled chromium wouldn't be bad.

@Ahrotahn
Copy link
Contributor

I did some experimentation earlier this week and found a way to add a new internal page that shouldn't cause future headaches.

I think the FAQ, flags, support, and contributing pages make the most sense to link. The FAQ has answers to most of the common questions people have and the flags doc should cover the rest. The support page might help direct people to the correct repo if their issue is platform-specific. The contributing page probably isn't necessary but maybe it could get some other people involved with the project.

Are there any other pages would be a good idea to include? Is there any specific verbiage that would be useful to have on the page?

Another interesting thing to consider is that since it's an internal page we'd be able to link other ones. So we could have a link to chrome://flags or we could mention that cookies are cleared by default on new profiles with a link to chrome://settings/cookies for example.

@jstkdng
Copy link
Member

jstkdng commented Jun 10, 2022

Would it be possible to be able to change some settings in that page? Like the default cookie policy and/or the default search engine

@networkException
Copy link
Member

I think we should stick for a first launch page for now and look into further customizations down the line.


While this would advance the project more in the direction of a browser instead of a patchset it could also allow us to better address the concerns of different audiences:

Out of the box we could leave all settings to their default for example, provide a hardened or more privacy oriented profile directly on the welcome screen though.

If a user wishes to just use chromium with no distractions they would have to never have that welcome screen shown again.

Another user might want to get an update summary for every release with new flags / settings to choose from.

@tomasz1986
Copy link

tomasz1986 commented Jun 10, 2022

the FAQ

It would probably be useful to update the FAQ at least a little before linking to it on a more "official" level, as right now it contains some extremely outdated information, e.g. about how to install and use Adobe Flash, which doesn't even apply or work anymore.

@networkException
Copy link
Member

Well the FAQ is already linked everywhere, we can update it whenever anyways

(...the flash player section should probably be removed)

@PF4Public
Copy link
Contributor Author

I think, we should include some of the most often asked questions into the first-run page in text in order to answer those questions right from the start without needing to click links.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Not actionable yet; need community feedback enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants