RFC Authors' profiles look.

[MSusik]

Hello!

Lately I've beeen working on moving the authors front-end to pu. I tried to keep the look with the current box order. Unfortunately it seems that that we don't have enough space to do that. Here is a screenshot from 1920x1080 monitor from demosite:

The boxes that in my opinion look wrong:

• Personal details - rows don't fit.
• Publications - this box should be wider so that most of the rows don't break in half
• Papers - I wanted to use Bootstrap table to make it more readable. One column has been cut-off
• Publication-graph - This is the smallest problem, we can create smaller icons.

_{^{I don't want to discuss here any issues regarding compability with Invenio. This RFC aims to gather requirements for Inspire next author's page (and that's why it is here) and look for a solution for Inspire only. I need to know what will be needed by Inspire before I start writing the demosite version. The solution implemented by me will work well for Invenio framework.}}

Proposal

Redesign. I know that it took a lot of time to develop current look, but we need to go forward.

@glouppe @jmartinm @kaplun

[MSusik]

How can I call Laura here?

[jalavik]

On your resolution, I guess it would look better if it was not having so much empty space to the sides? We can always reduce that, no?

[MSusik]

We can, but I believe fluid design that leaves blank spaces on sides is a part of a modern web design.

[jalavik]

I agree design-wise it has potential for improvement. And looking at it, we can probably even save space by not putting absolutely everything in boxes.

[MSusik]

And looking at it, we can probably even save space by not putting absolutely everything in boxes.

Yes!

[giokokos]

If you want to have a page that is the full width of the browser at all times, and fluid, you will have to use the .container-fluid. Since Bootstrap 3 is mobile first, the default state is the single column mobile width. So if you want everything bigger to function as just one responsive “100% fluid” width, you use this class and wrap your rows in it.

<div class="container-fluid">
  ...
</div>

If you want to have a better control over your layout, you might as well use responsive layout which is the combination of fluid layout + media queries where media specific CSS are defined for certain browser resolutions.

[MSusik]

Thank you for your input.

However, the page design should be integrated with the rest of the project which uses the default behaviour. The problem is not a technical one, but a design one.

As the rest of the portal tries to fit in, the authors module should not break this rule. http://invenio-demo-next.cern.ch/search?p=author%3A%22Ellis%2C+J%22 http://inspirelabstest.cern.ch/search?ln=en&p=author%3A%22Ellis%2C+John+R.%22&of=hb&action_search=

Are there any exceptions?

[pherterich]

What about trying the 2 column design the current version switches to if you reduce the browser size? And then we can discuss about re-arranging the small boxes...

[pherterich]

Once @espacial is back, we can look into the old author page testing results and share them with you to have more data we can base our decisions on.

[suenjedt]

Yes, there was a detailed analysis of the arrangment of the boxes. Nevertheless I would like to suggest as well to get rid of some "white space", some useless boxes perhaps and framing.

[MSusik]

Two columns.

[giokokos]

Are there any exceptions?

If you visit the deposition form you can see that the form doesn't follow the parent container width, thus we used media query to adjust its width, so the form elements don't expand long.

A design approach could be (using the default Bootstrap breakpoints):

• 3-column layout for Large devices Desktops (≥1200px) and use the container-fluid which takes the whole screen size
• 2-column layout for Medium devices Desktops (≥992px) and Small devices Tablets (≥768px)
• 1-column layout for Extra small devices Phones (<768px).

[pherterich]

I think what @giokokos suggests is exactly how the current design adjusts. Somehow, the 2 columns make it look like there's even more empty space...

[minnsoe]

@MSusik Just to drop my 2 pence, we've run into this before with @WohthaN. In order to work around the constraints we had to redefine the default breakpoints and do 'Really Bad'(TM) things.

I agree that it is a matter of design and we won't know if it's suitable until there are built in methods to collect metrics that can be used to assess usability.

Essentially a design that works shouldn't be changed but in this case we do not have enough statistical samples to neither confirm or refute that. I suggest you play with the fluid container as @giokokos suggests but with the vanilla defaults in the library. Ultimately, if you feel that it isn't moving anywhere it might be worth holding a joint meeting with IT (consider that some parts of Authors can be an 'extension' of Invenio).

Hope this will be of use.

[jmartinm]

I agree with @giokokos suggestion. You are currently running in the Invenio demosite with the default css, you should not be limited by that to try to fit everything in the width of the search bar.

Have a look at the fluid options to see if you can optimize the space available, all that white space is too much at the moment (in the screenshot)

[minnsoe]

A combination of the suggestions by @pherterich, @suenjedt and @jalavik could work.

Pull some things out of the boxes because the padding and margins tend to waste a lot of space. Drop some boxes by merging a few (call a meeting if needed) and re-order any small remaining boxes. This can probably done whilst preserving the column semantics.

@jmartinm, technically yeah. It'll probably look weird :confused: with the search bar.

[MSusik]

@jmartinm Why all that white space is too much?

Check those website which have much more content on a single page than we: https://www.yahoo.com/ https://www.facebook.com/ http://digg.com/ http://www.ebay.com/

It is not a coincidence that people use this layout. One should be able to see the whole page at a single glance in order to navigate quicker and find all the needed information. I must say that I am suprised that you suggest to break this just because the old look doesn't fit. Please tell me why should I do it, what are the advantages of such solution, as I see none besides the fact that the current one is ready and we won't have to spend time on it.

If this is your reasoning I'd like just to remind that every time I ask why some things are solved wrongly on master, I hear that sb had to follow deadlines, there was no enough time, etc.. And, in this case, we are going the same direction one more time.

If we want any changes, it is the best time to design them. Authors team just started moving things to pu and we would like to get rid of every problem that was occurring on master. One change that we would like to implement is including all the information needed for rendering the page inside author's record. So, what will be visible on the page is important also for backend.

I like @MinnSoe 's approach, I'd like also to talk about what should be included on this page, should we create another tabs (Manage profile will be almost empty on pu), etc.. Anyway, this means redesigning the page.

[jalavik]

@MSusik I think the underlying point is that earlier this year considerable effort was made to do usability testing with users and reiterating the design - including what should be on the page etc.

As I said, the design can (and should) be verified/iterated once more for pu. We should just remember to take into account all the work that already was done on this topic.

[MSusik]

@jalavik I agree, but this should not be a blocker for changes. Anyway, the results of the usability testing should be a base of the new design.

[glouppe]

I believe the problem is in fact more general than the width of profile pages. The question to answer is: do we want the look and feel to be consistent, Inspire-wise?

If yes, then there need to be general decisions over the overall look and feel of the interface (header, footer, containers, general styles for the elements, responsivity of the design, etc). If we go that way*, and if we chose a fixed page width (for a given device), then the profile page will require some changes with respect to master, since obviously everything cannot be fit. Provided we take into account user input, I believe this is the direction to go, but this is just my opinion.

*: Note that this seems to be the case from what is already in pu. Search, records, index, submission, etc all share the same fixed page width. Hence I would find it a bit surprising to make an exception of the profile pages.

[jalavik]

@glouppe Indeed the width should be consistent throughout the page. I guess people were questioning if the current width is the correct one. As you said it is all connected to the general style, and yes, we definitely want to have a consistent look-and-feel on labs.

[kaplun]

It is not a coincidence that people use this layout. One should be able to see the whole page at a single glance in order to navigate quicker and find all the needed information.

I think this point from @MSusik is quite important indeed, and I am not sure if it was considered when the profile pages were designed on master (maybe it was, but I can't remember). Indeed, in terms of ergonomic of web pages it is quite a requirement that pages don't get past a certain width, otherwise it can become physically difficult to read them (for the same reason you don't have physical books with pages larger than a certain width).

In the usability iteration we wen thorough in the past, for profile pages, I think we kind of answered the question: how to best arrange the given boxes in a usable way so that it adapts in a conistent way in all devices. We should probably get further and decide what actually is sensible to display at all in an ergonomic way and what can be moved to say a different tab/accordion/section, whatever. Imagine that in the future we are going to add many more pieces of information to this profiles (e.g. new metrics and graphs), and the same style is going to be wanted for Institutions, for Journal, for Experiments...

[jmartinm]

Sorry maybe the last comment was confusing on my side. Indeed I agree (we seem to all do) that a consistent width is the way to go, I was just trying to make clear that you should not be constraint by the current css on the demo site when deciding what that ideal width would be (and at first glance the screenshot seemed narrower than usual)

On http://inspirelabstest.cern.ch for example the current width is 1170px (default responsive Bootstrap)

So with that in mind, and looking at all the conclusions extracted from the user testing I would not see any problem at all at rethinking what boxes should be shown and their design (currently I agree there is too much information compressed in that page)

I would recommended creating 2/3 mockup proposals so that you can iterate faster and share it to get some feedback

[espacial]

First approach...

[kaplun]

This is so cool!! Finally a new INSPIRE as it was supposed to be :smile: clean, modern, simple, and usable.

Just some opinions on my side:

• I like a lot the new logo! Just wondering if it's possible to add a drop more of color between the orange dot and the orange flask. Just not have a whole white desert.
• The edit icon next to the name, is it a hint, a la LinkedIn, for letting the user just edit his/her preferred name and/or affiliation? If that is the case that is great :smile:
• The pie chart, albeit nice, should not be used for the given type of data (i.e. number of paper with given citation number) it would bias towards always displaying a big slice of low-citation paper, and forget to advertize even a single very remarkable paper.
• I like the possibility to claim papers via the button in the publication lists.

Great work!

[jalavik]

https://github.com/inspirehep/inspire-next/issues/138#issuecomment-65046754 Great stuff :+1:

[MSusik]

@kaplun

The edit icon next to the name, is it a hint, a la LinkedIn, for letting the user just edit his/her preferred name and/or affiliation? If that is the case that is great :smile:

The intention was that it will redirect to pre-filled submission form that will be used to edit the profile.

The pie chart, albeit nice, should not be used for the given type of data (i.e. number of paper with given citation number) it would bias towards always displaying a big slice of low-citation paper, and forget to advertize even a single very remarkable paper.

What would you suggest here? We definitely should drop all the names that are currently used (like renowned papers), but what should exactly go there is probably a subject for a discussion.

[kaplun]

What would you suggest here? We definitely should drop all the names that are currently used (like renowned papers), but what should exactly go there is probably a subject for a discussion.

Indeed, we should have some input from some expert in visualization (maybe Eamon when he will come?) For this specific graph I simply wanted to point out that the pie chart (or any other tool which would explore relative numbers) should not be used here as number are having each a value. Maybe we could use sort of badges like it was done for the 500+ 100+ milestones. E.g. we could give a golden badge with the number of "Renowned papers", then a silver badge for the "Famous papers" etc...

[MSusik]

Maybe we could use sort of badges

Another idea:

New achievement unlocked: Your paper was cited 100 times :100: (+250 XP) LEVEL UP!!! Your are now level 3. Keep up the good work for HEP.

:stuck_out_tongue_closed_eyes:

[MSusik]

Badges are a nice idea, but are they representable enough? Will user see easily the needed information?

[MSusik]

First implementation:

The graphs are empty as I don't know which content will be showed and how.

[glouppe]

Thanks for the update Mateusz.

Here are some personal comments:

• The list of publications would need some love. I would rather show it as a table with 3 sortable columns (title, citations, year). That way, it makes it easy to find the most recent (by sorting by year) / the most important (by sorting by citations) / a particular (by sorting in alphabetical order) publication(s) of a given author.
• I am not convinced about the relevance of the pie chart, nor I believe the page should be cluttered with 3 different plots. I remain convinced that the citation graph, shown as a bar plot per year, is the most appropriate.
• In my opinion, the large edit button on the top right should be in the same color as "Claim papers" or "Edit details".
• The position history as a table feels odd and empty when some fields are unknown (which is often the case). I think a solution would be to not use a table but a simple list of elements "< institution > [, < rank >] [, < period >]".
• Shall we consider the possibility to show a picture? When you go to conferences and want to meet someone, having the picture of researchers is a very helpful thing.
• Shouldnt the h-index be shown in the same way as the 3 metrics below? Why is it emphasized this way?

[kaplun]

The list of publications would need some love. I would rather show it as a table with 3 sortable columns (title, citations, year). That way, it makes it easy to find the most recent (by sorting by year) / the most important (by sorting by citations) / a particular (by sorting in alphabetical order) publication(s) of a given author.

:+1:

I am not convinced about the relevance of the pie chart, nor I believe the page should be cluttered with 3 different plots. I remain convinced that the citation graph, shown as a bar plot per year, is the most appropriate.

:+1: that's what I also meant in:

For this specific graph I simply wanted to point out that the pie chart (or any other tool which would explore relative numbers) should not be used here as number are having each a value.

In my opinion, the large edit button on the top right should be in the same color as "Claim papers" or "Edit details".

:+1: (and should it be so large? E.g. imagine guests users seeing this on every profile...)

The position history as a table feels odd and empty when some fields are unknown (which is often the case). I think a solution would be to not use a table but a simple list of elements "< institution > [, < rank >] [, < period >]".

Nice

Shall we consider the possibility to show a picture? When you go to conferences and want to meet someone, having the picture of researchers is a very helpful thing.

:+1: Actually for users having set their email and having a gravatar we could directly use that one. In this way we would not be pushy on user, by simply reusing the official picture they already decided to make public and associated with their email.

Shouldnt the h-index be shown in the same way as the 3 metrics below? Why is it emphasized this way?

I guess that's because the h-index is the number that theoretical physicists are using nowadays to compare people.

[kaplun]

Badges are a nice idea, but are they representable enough? Will user see easily the needed information?

I am not sure about the best way indeed to display such information... But pie charts can't really be used for this type of numbers... Maybe we should ask our users. They are doing plots all day long. How would they best represent these numbers in a publication?

[glouppe]

Is this information relevant at all? The distribution of citations is nearly always a long tail distribution. Provided that you can sort the publication list by #citations, then you will directly spot those that are remarkable and notice that most of the others are cited not often. Having this feature, adding such a graph / badges seems redundant, but this is just my opinion.

[MSusik]

The list of publications would need some love. I would rather show it as a table with 3 sortable columns (title, citations, year). That way, it makes it easy to find the most recent (by sorting by year) / the most important (by sorting by citations) / a particular (by sorting in alphabetical order) publication(s) of a given author.

The only argument against that I can come up with is that as we're having search engine (and probably the search bar should be included on the top of the profile) this will duplicate the same functionality.

I am not convinced about the relevance of the pie chart, nor I believe the page should be cluttered with 3 different plots. I remain convinced that the citation graph, shown as a bar plot per year, is the most appropriate.

If we want to visualize more data, I think another solution might be to create one, but big and very powerful chart with toggles.

In my opinion, the large edit button on the top right should be in the same color as "Claim papers" or "Edit details".

True, will be changed.

The position history as a table feels odd and empty when some fields are unknown (which is often the case). I think a solution would be to not use a table but a simple list of elements " [, ] [, ]".

Good idea, will be changed.

Actually for users having set their email and having a gravatar we could directly use that one. In this way we would not be pushy on user, by simply reusing the official picture they already decided to make public and associated with their email.

Maybe we should use both options? Use gravatar if it is available and additionally allow user to upload a picture. Where should it be displayed? Inside Personal details box? Or next to the title?

(and should it be so large? E.g. imagine guests users seeing this on every profile...)

We can make it smaller if sb is not viewing his own profile

I won't take part in the discussion what to show on charts, and how to represent the h-index, as I have completely no idea what is desired by users.

[jmartinm]

Hi Mateusz. That's starting to look very good! Some questions/comments:

1) What is the big update button supposed to do? I would not be sure what to expect when I click on it. Is it updating just the top part with the name? Or the whole profile? We already have 'Update details' and 'Claim papers' which are editing parts of the profile. Do we need this extra entry point?

2) Below the name of the user, what is exactly the content of that list?? I have been here for a while and I have to admit I don't know what it means or why is useful ;). The first two I think are subjects. The problem I have seen using those subjects in the submission forms is that this is a INSPIRE internal and people are not familiar with them (they are familiar with the arXiv ones)

3) As you have other green elements (plot, h-index) apart from the update buttons they are not as clear/prominent. I would try with the orange ones (like in LABS front page)

4) For the list of publications, as you mentioned, we did not want to replicate the whole search engine again. So one solution would be to make clear with a title: Latest publications or More cited publications and show just 10. Then after the last one have a link "Show all" that will open in a new tab the search with all the publications.

5) Just a design tendency that I see a lot now is to leave a lot of breathing room in between elements, so in all boxes: Publications, Keywords and Co-authors it would be nice to have a bit extra space in between the elements of the list for better readability.

Hope it helps!

[MSusik]

Do we need this extra entry point?

I'm not sure, we (I and Laura) thought that It might encourage more users to update profiles.

Below the name of the user, what is exactly the content of that list??

It was supposed to show a very short description which would define person's interests (field, categories, etc.) In this iteration there are 2 keywords and 2 subject categories. Obviously, it is discussable.

I would try with the orange ones (like in LABS front page)

Might be a good idea.

For the list of publications, as you mentioned, we did not want to replicate the whole search engine again. So one solution would be to make clear with a title: Latest publications or More cited publications and show just 10. Then after the last one have a link "Show all" that will open in a new tab the search with all the publications.

True, but it creates another layer of indirectness (I don't know which solution is better, though).

Just a design tendency that I see a lot now is to leave a lot of breathing room in between elements, so in all boxes: Publications, Keywords and Co-authors it would be nice to have a bit extra space in between the elements of the list for better readability.

Here I disagree. First of all, Bootstrap already creates a lot of whitespaces. The problem with them is that they are really uniform - everywhere you have the same padding, margin, etc. IMO it makes the page less readable if you overuse them.

Moreover, this is not such an important information, maybe it is better to hide it by squeezing.

[jalavik]

Regarding the proposed table view of the publications, it might be worthwhile to look into a plugin like DataTables which allows sorting on columns and pagination etc.

There are probably great js plugins as well for chart/graph display as well if you want to make the plots more interactive.

[MSusik]

Sure, datatables is already used on master. In this mockup I used flot for the pie-chart.

[PXke]

Hello, just an insight from outside. If you decide to implement badges, it would be cool to have the possibility to disable it.

A bit like phabricator has its phun mode and pro. Not saying that badges are unprofessional but it can be perceived like that.

It would be cool to have a panel like piwik. Where every simple table can be turned into a plot. (On demand at base it is a table) It allows to summarize data when sometimes we have to many.

Cheers, and have fun !

[kaplun]

This has been superseded as like as #218