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

Templates on welcome page #10020

Merged
merged 19 commits into from Jun 21, 2019
Merged

Conversation

m-kuhn
Copy link
Member

@m-kuhn m-kuhn commented May 16, 2019

Shows the available templates on the home screen.

Templates can be shipped through the current user profile path or an AppData path with the suffix project_templates (That needs docs for sysadmins ;) ).
If the template is in qgz format, the embedded preview.png will be shown as a thumbnail for additional user happiness.

Since there is now a preview image inside the zip, this could also be used on modern operating systems to be extracted and shown in the file explorer thumbnail (not part of this PR ;) ).

image

Sponsored by the QGIS project

@m-kuhn m-kuhn added the Feature label May 16, 2019
@nirvn
Copy link
Contributor

nirvn commented May 16, 2019

For the majority of users who don't have an extra wide screen, how does the welcome page looks like? That seems to be a bit problematic.

One possibility: transform the Recent projects area into a tab bar, and have two tabs (recent projects and project templates). You could style the font size on those tabs to be bigger to also act as large headers.

void QgisApp::createPreviewImage( const QString &path )
{
// Render the map canvas
QSize previewSize( 250, 177 ); // h = w / std::sqrt(2)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider hi-dpi previews too?

Copy link
Member Author

@m-kuhn m-kuhn May 17, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you save two pictures?
The current one is rendered in "current screen scaling", directly taken from the map canvas (and therefore superfast), so possibilities are a bit constrained.

void QgsTemplateProjectsModel::scanDirectory( const QString &path )
{
QDir dir = QDir( path );
const QFileInfoList files = dir.entryInfoList( QStringList() << QStringLiteral( "*.qgs" ) << QStringLiteral( "*.qgz" ) );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this case insensitive by default?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess. NoFiter is specified by default and QDir::CaseSensitive is listed in filters.

previewPainter.setRenderHint( QPainter::Antialiasing, true );
previewPainter.setPen( Qt::NoPen );
previewPainter.setBrush( Qt::black );
previewPainter.drawRoundedRect( 0, 0, previewImage.width(), previewImage.height(), 8, 8 );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi dpi compatibility?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compatible with the recent projects and with the image size. Unless something is changed #10020 (comment) here and aligned in recent projects, I wouldn't touch that.

src/app/qgswelcomepage.cpp Show resolved Hide resolved

QFileInfo fileInfo( index.data( QgsRecentProjectItemsModel::NativePathRole ).toString() );

QMenu *menu = new QMenu();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Leaks?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't

connect( menu, &QMenu::aboutToHide, menu, &QMenu::deleteLater );

I guess it's better to delete it when it's hidden then keeping it around for the whole lifetime of the app

src/app/qgswelcomepage.cpp Outdated Show resolved Hide resolved
src/app/qgswelcomepage.cpp Outdated Show resolved Hide resolved
@m-kuhn
Copy link
Member Author

m-kuhn commented May 17, 2019

For the majority of users who don't have an extra wide screen, how does the welcome page looks like? That seems to be a bit problematic.

I am testing this on a 14" notebook. But with hidpi.
The current layout is based on this proposal here: qgis/QGIS-Enhancement-Proposals#102 (comment) . Maybe we can reorder a bit to clean things.
But your proposal with the tabs sounds good too because I guess it will look a lot tidier.

@nirvn
Copy link
Contributor

nirvn commented May 17, 2019

@m-kuhn , the proposal linked dramatically changes the way projects (recent or template) are laid out (i.e., text below project screenshot results in much narrower width).

I'd say this PR needs to implement either possibilities here, namely revamping project items to look like the mockup, or having header tabs. I have no strong opinion on which approach is better :)

@nyalldawson nyalldawson added the Frozen Feature freeze - Do not merge! label May 19, 2019
@nyalldawson nyalldawson added this to the 3.10 milestone May 19, 2019
@m-kuhn
Copy link
Member Author

m-kuhn commented May 20, 2019

@nirvn better like this?

image

@nyalldawson
Copy link
Collaborator

To be honest, I preferred the "all in one screen" approach to the (more hidden) tab approach. What if we just reduce the size of entries in both lists so they fit nicely in one page? We've plenty of room, they should be able to fit :)

@nyalldawson
Copy link
Collaborator

( keeping in mind that one of the big motivations behind showing templates on the front page was to be able to provide an osm template, so that totally new users had an immediate visual queue how to create and start with a map with some content)

@roya0045
Copy link
Contributor

Just a quick question, for the average user, how prevalent should templates be? How much will they be used in reality? Should the average user deal with them?

I'm not sure how much of a pain to implement this would be but could users have some options to do with dual or tabs?

I'm sure some users will never use them or seldom while others might integrate them in their workflow, and for these two cases, the prevalence of the templates in the welcome page should be dictated by those two factors and by their personal preference.

Just my two cents, I hope this helps.

@roya0045
Copy link
Contributor

Oh and also, from a graphical point of view, would it be better to have the preview as is or have the preview fill the the whole rectacle (the preview would only be a fragment of the canvas ) and have the text on top of it with some settings to ensure that everything is always readable.

I feel that using the preview the preview as a small square separate from the text create a lot of deadspace, and I think this is more apparent with the side by side layout. I am aware that this is not the place to discuss such things but I just wanted to plant a seed.

@nirvn
Copy link
Contributor

nirvn commented May 21, 2019

@nyalldawson, "we have plenty of room", speaking for yourself! 😉 this is how this dual column looks like on my screen:
image
Note: while I have the browser panel open, that right docked panels area is for style panel, processing, stats, etc., so it's not overly wide to begin with

My problem with this two column design is that IMHO it's already too narrow, but let's say we think it's not, it'd still be "the end" of that design as nothing else could be added. The tabs approach adds more flexibility (read a third tab with a QGIS latest news feed).

Also, if we go ahead with tabs, we should hide tabs that have no content (i.e. with I have zero templates on my machine, hide; if I have zero recent projects, please hide! etc. 😄 ). If we opt for that approach, IMHO QGIS should ship with a few templates, and upon first launch of QGIS the user would only see the templates tab, with the nice screenshots of OSM basemaps et cie.

I also think it'd be good UX to remember which tab the user last focused. If someone prefers to see recent projects upon launch, he/she will be shown that -- if someone prefers templates, having focused that last would return to templates.

Big +1 for tabs from me.

@nyalldawson
Copy link
Collaborator

@nirvn

My original message was suggesting that we reduce the size of entries to make everything fit, that's what I was meaning by saying we had room (as in, the items are already quite large and heavily padded).

But, shouldn't we ideally hide all the panels here anyway? I agree that with them open the view is cluttered, but I don't think they SHOULD be opened until either a project is opened, the "new project" button is clicked, or a layer added. Again, for a first time user, the difference in "wow what the heck ARE all these buttons and stuff" factor would be huge if we hide away the default layer tree/browser arrangement.

I really am not a fan of the tabs.

The other consideration is which we must include is that in 3.10 we'll be adding the news feed to the welcome screen too. This HAS to be on the first screen, and cannot be hidden away in a tab. So these same questions will just come right back at us 😉

@nyalldawson
Copy link
Collaborator

@m-kuhn

What do you think about adding a permanent entry to the list for "new blank project"?

@nyalldawson
Copy link
Collaborator

@m-kuhn
One other thing which just occurred when looking at these screenshots -- do we really need to show the project template path here? Most of the time this will be useless information for users. I'd rather show some of the the template project's metadata instead of this, e.g. abstract/tags/...

@nirvn
Copy link
Contributor

nirvn commented May 21, 2019

For the sake of emptying the bag and pick the best option here, let me continue arguing for tabs (while acknowledging you make some valid points 😉 ).

The one positive of placing the news feed into its own tab would be to only load the news feed upon focusing on the tab. That has a few good side effects: a/ we could have a more dense news feed (for e.g., not only showing QGIS blog posts, but also a few of the latest QGIS flickr maps, possibly a list of ongoing crowdfunding efforts, etc.; essentially it'd be a QGIS community hub of some sort), and b/ if we have the recent project / template / news feed into a single panel, we'd probably end up inciting more users to disable the news feed entirely as it'd also load upon launch.

@nirvn
Copy link
Contributor

nirvn commented May 21, 2019

@m-kuhn
One other thing which just occurred when looking at these screenshots -- do we really need to show the project template path here? Most of the time this will be useless information for users. I'd rather show some of the the template project's metadata instead of this, e.g. abstract/tags/...

+1 to hide the template path.

@nyalldawson
Copy link
Collaborator

@nirvn

The one positive of placing the news feed into its own tab would be to only load the news feed upon focusing on the tab. That has a few good side effects: a/ we could have a more dense news feed (for e.g., not only showing QGIS blog posts, but also a few of the latest QGIS flickr maps, possibly a list of ongoing crowdfunding efforts, etc.; essentially it'd be a QGIS community hub of some sort), and b/ if we have the recent project / template / news feed into a single panel, we'd probably end up inciting more users to disable the news feed entirely as it'd also load upon launch.

Checkout the corresponding QEP regarding the news feed - we're going for a highly moderated/curated feed, with time limited articles, and with the future option even of geo-fencing news items (so you wont have to see announcements of conferences on the other side of the world). It's all been designed to avoid saturating users, ...but... we really need this content to be in their faces, or the whole exercise becomes meaningless.

Motivated users already have channels for seeing QGIS map showcases and other similar content, but what we NEED from this is a way to force push content into the eyes of the 99% of QGIS users who aren't actively seeking out this content.

@nirvn
Copy link
Contributor

nirvn commented May 21, 2019

Regarding the mock up (specifically the above-referred proposal to modify the recent project/template item design, I'm not 100% sure how we'd go at it in the context of a non-fixed width for those lists. If we adopt the mock up design (project screenshot on top, info at the bottom), it might look weird if the columns are very wide (look at Mathias' screenshot on top for e.g., and imagine that design).

If we keep the current approach but reduce the text size and padding (and the screenshot a bit?), it'd probably be a more flexible design.

Is ultimately the idea for the welcome page to take over all of the main window or we'd still keep panels and toolbars?

@nyalldawson
Copy link
Collaborator

Is ultimately the idea for the welcome page to take over all of the main window or we'd still keep panels and toolbars?

I think panels should be hidden, see:
#10020 (comment)

@nirvn
Copy link
Contributor

nirvn commented May 21, 2019

@nyalldawson , got it.

@m-kuhn
Copy link
Member Author

m-kuhn commented May 21, 2019

Just a quick question, for the average user, how prevalent should templates be? How much will they be used in reality? Should the average user deal with them?

That will depend a lot on the user, but they should at least help as a "starting aid" for first-timers.

I'm not sure how much of a pain to implement this would be but could users have some options to do with dual or tabs?

-1 for an option. We shouldn't cover bad UX decisions with more options which are bad UX themselves.

What do you think about adding a permanent entry to the list for "new blank project"?

+1, have been thinking about that too

One other thing which just occurred when looking at these screenshots -- do we really need to show the project template path here? Most of the time this will be useless information for users. I'd rather show some of the the template project's metadata instead of this, e.g. abstract/tags/...

Paths: not really required, agreed.
How expensive is it to parse the whole XML?

And for hiding the panels, let me see how easy/doable this is on a technical level...

@nyalldawson
Copy link
Collaborator

@m-kuhn

Paths: not really required, agreed.
How expensive is it to parse the whole XML?

If you actually mean parse the XML, I'm -1 (it's too fragile). If you mean open the project as a project, it's mostly an issue about loading layers. I think we could do with a "don't resolve layers" flag in QgsProject to allow for this use case.

And for hiding the panels, let me see how easy/doable this is on a technical level...

There's currently the ctrl+tab shortcut which toggles panels -- maybe you can hook into the same approach this uses?

@nirvn
Copy link
Contributor

nirvn commented May 21, 2019

-1 for an option. We shouldn't cover bad UX decisions with more options which are bad UX themselves.

I'm also +1 to this -1 😉 as much as we clearly have some diverging opinions on the best approach (columns vs tabs), let's just settle on what most feel being the right approach, and code the very best experience out of it.

@andreasneumann
Copy link
Member

Hi,
I would also prefer a version without tabs and with all three columns visible. Panels that aren't browser panels should be hidden by default, while the start-screen is active.

Not hiding the browser panel would potentially have some value for the user, as the browser allows to open projects from the file structure.

But if such logic is too complicated I would just hide all panels by default and use the whole width available in the window for the start-screen.

Just my two cents,
Andreas

@m-kuhn
Copy link
Member Author

m-kuhn commented May 21, 2019

I think hiding the panels should be doable.

My main considerations for the layout:

  • Tabs reduce discoverability
  • Showing two (or even three) columns clutters the interface

I wonder if colors for the columns would help (or some other visual cue that the items serve a different purpose)

@andreasneumann
Copy link
Member

Well the news-feed column is a must and is more important to us then the template column. If it comes to deciding what columns to show.

In the QGIS PSC meeting people had mixed feeling about the project templates. Some think they are useful and important, some not and wouldn't use them.

But the main reason that QGIS.ORG is funding this initiative is to get the news feed together with crowd-funding campaigns out to our users. We think that many of our users don't visit the usual communication channels (Website, blogs, social media) but may see QGIS news and crowd funding campaigns if they appear on the start screen.

@nirvn
Copy link
Contributor

nirvn commented May 21, 2019

Trying not to diverge too much from the PR's goal here, I have to re-iterate the importance of a news feed column implementation that'll allow for it to be disabled altogether.

It seems this PR shows there are more people supportive of columns, let's settle on that. In the welcome page column implementation, IMHO the best approach is to allow users to show/hide each column (in addition to intelligently hiding a given column that has no content). So instead of having a "show welcome page" option in the settings, it'd become: welcome page content: [x] recent [x] template [x] news.

@nirvn
Copy link
Contributor

nirvn commented May 21, 2019

By default, all three columns are active. If someone doesn't care about template, he/she can disable that. If someone doesn't care about news (or lives in an environment where bad actors are profiling online users for malicious reasons and thus doesn't want to be identified as a qgis user), he/she can disable that. Etc.

@m-kuhn m-kuhn force-pushed the teamplates_on_welcome_page branch from b2722f9 to 9e45626 Compare May 27, 2019 12:57
@stale
Copy link

stale bot commented Jun 10, 2019

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

  • that all unit tests are passing

  • that all comments by reviewers have been addressed

  • that there is enough information for reviewers, in particular

    • link to any issues which this pull request fixes

    • add a description of workflows which this pull request fixes

    • add screenshots if applicable

  • that you have written unit tests where possible
    In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
    If there is no further activity on this pull request, it will be closed in a week.

@stale stale bot added the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Jun 10, 2019
@m-kuhn
Copy link
Member Author

m-kuhn commented Jun 10, 2019

Dear @stale bot, I'd like to keep this open if it's ok for you. I'm basicaly waiting for the winter to be over and everything melting again before merging this.

Meanwhile if you could add the merge after thaw label instead of the stale label, I'd be more than happy.

Thank you for your collaboration,
sincerely @m-kuhn

@stale stale bot removed the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Jun 10, 2019
@nyalldawson nyalldawson added Merge After Thaw For approved PRs which are ready to be merged as soon as master is thawed and removed Frozen Feature freeze - Do not merge! labels Jun 11, 2019
@nyalldawson
Copy link
Collaborator

Here, have the coveted "merge after thaw" label 🍺

@m-kuhn m-kuhn merged commit 5e1ca35 into qgis:master Jun 21, 2019
@m-kuhn m-kuhn deleted the teamplates_on_welcome_page branch June 21, 2019 14:13
@alexbruy
Copy link
Contributor

@m-kuhn seems welcome page with templates and recent projects now always shown on QGIS startup, even if in settings I choose to open new project on start. This is pretty confusing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Merge After Thaw For approved PRs which are ready to be merged as soon as master is thawed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants