Open rgaudin opened 3 months ago
What is the status of this issue? I belive we teally need one at this stage.
I was assuming this was only UI revamping but I see important features appearing and disappearing.
I also see no mockup I can have a look and on which building an opinion.
Internal search feature will be removed
I'm not sure to understand what it means, but if I get ot right I'm 100% against this.
In general I'm not confortable with non obvious AND non-argumented (written) moves.
Logo won't be clickable anymore (dont repeat reader feature)
Which logo is meant? If this is the logo on the top left, then would be interest to understand the rationals behind this decision.
We've had this discussion several times and you keep coming back to it. It really sounds like you don't want it to happen and you're not satisfied with how it's being done. Maybe we should just close the issue and move on.
The process has already been explained. Has a U/I makeover, this starts with mockups that are discussed live (in calls you did not participate to) and changes/features debated with the designer, the user-representative and the developer. The latest iteration awaits @Popolechien's approval so there is no Accepted one to share on Github.
Should the mockup be posted on Github for others to comment on? That defeats the purpose of doing it live: otherwise it's re-doing the same discussions/arguments with multiple stakeholders.
Should it be entirely on Github and not live? All arguments would then be written but we've seen in the past that this makes decisions very difficult.
Should there be a post-discussion document that shows the mockups annotated with all decisions? Would be great!
Status: there is a mockup that I think is ready but @Popolechien was not present in last meeting and should give feedback on. Development has no started yet (unrelated to previous point)
@rgaudin Whatever what is done: tracability, accountability, rationality and transparency is a wish. I understand that this is difficult to fullfill all of this all the time, but product or even UI design should not work differently. Even if decisin making is challenging, giving-up on all these principle is not the solution.
Fondamental points:
[!NOTE]
This is all based on mockups (Desktop version). The black bar on top of the mockup pages represents Kiwix reader features.
[!WARNING] The mockups are hosted on Adobe Review
It means those can be updated @siemsie please freeze those ones as v3 Only comment on Github and not via the Adobe's review feature
Previous UI was a Single Page App built using a small HTML shell and a piece of JS that reads the list of entries from a JSON file (into an in-browser DB) and displays it as a simple list (Icon/Title/Description/Authors). Clicking on the icon linked either to the file URL or a popup for a couple of mimetypes: audio and video.
The new approach is closer to a file browser albeit it is based on a two-step scenario (browsing and details page). It does support direct downloads though.
Moving away from SPA means that:
The individual page displays the entry's metadata:
Some file types can be previewed:
[!IMPORTANT]
It is a preview. It may not be comfortable for all use cases
Other file types have no preview. Instead, a large box with the type's icon and filename is shown. That whole box is clickable and serves as a direct-open link.
Consequence of the two previous point: with folder/subfolders it's easy to group files together should there be any need. This removes the need (and burden) of displaying multiple entries together.
In previous UI we had for instance the case of an audio book that was split into chapters and we were displaying all on the same popup.
Consequence of the file arborescence, we display where we are in the tree and allow jumping to any level easily (each level is clickable)
Folders are ZIM entries with URLs that can be shared as well.
Header logo was clickable and linked to the home page (which is an SPA 🙄). We removed the link as to not duplicate a Kiwix reader feature (all readers have a Home button)
Because it was an SPA and there could be an unlimited number of entries, previous UI had a search box which filtered (not live) the entries matching the title or description.
It has been removed as this feature (and sibling ones) are now offered by Kiwix reader natively. Search-related URLs will now be decent-looking as well.
Pursuing simplicity, ease of use and acknowledging that main use case is browsing (ie. discovering content), we have limited interactions to a File type filtering system. The is no sorting for instance.
It is understood that Kiwix search is good-enough to find a known entry and that Suggestion and Random are complementary features.
Navigating through the hierarchy is thus done by looking at the cards.
Excluding some entries by file type seems to provide a good ratio of usefulness over reduction.
The filters are on-by-default: all the file types are ticked. One can reduce the list of displayed cards by unticking some unwanted types.
A Select All button allows for quick back-to-all action.
The filtering is applied to what's on the screen:
#e9f4fa
) colored in mockup indicates the clickable-area (not visible)Previous UI gave access to file/popup only via click on the Icon. Access to indiv page is done by clicking on the card-wide top area of the card (from top to end of title)
Light Pink (#f8e7f1
) colored in mockup indicates the clickable-area (not visible)
pagination
optionPagination is rendered useless by the arborescence feature. Creator can now organize files (and its number per level) as sees fit.
random
optionRandom was default and we had a no-random
option that allowed one to keep the files in order. We used it on smaller sets.
With the arborescence feature empowering Creator, there is no point in having stuff random.
show-descriptions
optionThis was only present to balance the lack of UI flexibility (looked weirder without)
secondary-logo
) with Footer textBarely used and brought confusion more than anything else.
Instead, a footer-text
would be allowed. Sample use: Sponsored by X
main-color
option and computationHeader color was either settable by user, or automatically computed using the solarized version of the logo's main color.
Header color is now static.
We chose #FFFFFF
in order to acomodate people with white-background logo which have not been adapted for transparency.
secondary-color
option and computationFooter color was either settable or computed (solarized main color from the secondary logo). Footer is now static without constraint: there's no logo in the footer anymore.
You'll notice footer is not in the mockups. It's missing but it expected to be a simple indication of the end of the content. Maybe a #e4e6e5
line with the new footer-text
inside…
This is a meta-ticket archiving some notes related to an effort to redo/improve the nautilus UI.
Links
@siemsie will work on mocking a new UI up
Notes
Screenshots (current)