fabd / kanji-koohii Goto Github PK

NOTE: this test only applies to the landing page. Not sure how to get Google to test the member content.

Current live site:

Current staging site:

TODO

Parse detailed reports.

Considerations

• Host FontAwesome on the same server?
• Figure out why iPad Air 2 (2GB !) and Safari seems to take longer to load the staging site,what is the bottleneck?

The "unhide" solution for controversial / adult themed mnemonics is less than ideal. By suggesting something is hidden, it makes you want to "unhide".

Breakdown

• by default hide controversial stories (based on vote to report ratio)
• hence, don't display any hide / unhide links
• add user account setting to disable the filtering of moderated stories

I prefer to hide controversial stories by default , for a better experience for a public of all ages / culture. If the user doesn't want moderation, they can turn it off.

New user's stories will always show anyway since reports take some time to add up. And this would provide a sensible experience for new users.

All that, considering a simple solution. There's no one-size-fits-all answer here.

The pagers UX need to be simplified and made better for touch. They're also tiny nowadays on desktop so a common solution can be found.

Thoughts

• "Previous " and "Next" may be replaced with some FontAwesome icons like < and >
• I'm tempted to remove the Row selection altogether and just settile for a sensible default of 20 rows

Solutions

• First workable solution would be to just style everything larger, and/or use Bootstrap styles
• Not sure it's worth using VueJS here if I can make the existing php template work (if it's working, don't fix it...)

The FontAwesome icons are intended to be placeholders. They don't align and don't quite fit (eg. Flashcards kinda looks like two cards, but is " copy" icon).

• create icons myself (learning Inkscape)
• OR around May look for better alternatives in FromAwesome Pro.

Labeling issues like this design which could potentially be taken up by someone with the skills!

See related "Use SVG icons" #16

As seen in the screenshots, RTK3 is not "recognized" as finished (like RTK1 is) although its progress bar is full.
Edit: (RTK 3 is the second bar from the bottom showing 965/965)

This might be a mobile specific issue, but on my Android Sony Phone, it seems like some of the characters show up in a slightly different, but for me confusing, typeface. Here is a Screenshot of one of them

And here is a screenshot from my laptop:

Issue from @carcols

In the progress bar, I happen to have some kanjis from RTK3 that I added. It turns out that in the desktop site one can read "RTK3" as the "chapter", but on the mobile site it's empty.

Previously, when one wanted to "star" a story, when hovering the star would become yellow. On the new version the star stays always gray... which is fine but I guess everyone is conditioned to expect it to become yellow. It would be useful if the star would stay yellow once one "stars" a story, as it used to be.

I liked the Material Theme that @magnonellie made for Kanji Koohii. It reminded me the Flashcard Review page looks pretty cheesy today (imho) with some web2.0 vibes still in a few places.

(Though I would probably put a light theme by default, it would make a dark theme much easier by just changing the colours)

Use flat or semi-flat design that is more at home on iOS / Android as well as current desktop designs.

Practically speaking

• ditch the blue gradient background for something plain, or use the Koohii "cream" bg color to be consistent with the rest of the site

• replace pixellated icons with HI DPI icons (FontAwesome for now). Pass / fail, and the hamburger dropdown icon.. DONE (staging)

• use a centered layout on wider screens? I'm not too fond of the off-center flashcard on desktop

Improve data tables UX on mobile (flashcard list, etc)

• Extend table content edge to edge on mobile viewport
• Layout tables inside a horizontal scroll container
• Increase height a tad for rows
• Make entire rows as touch target where appropriate?

VueJS

• Create a VueJS component for the uISelectTable backend component. (keep the data in the backend for now, and let the backend do the paging)
  • Create a "row" sub component that is iterated on the client side
    • Use a "card" view or a "row" view depending on a view setting

Earlier feedback transfered from Google Group:

The main page looks pretty sharp, but the first thing that I note is that the images and logos look pixelated on my Nexus 5X screen.

Issues

• Fix pixellated images on the landing page
• Fix pixellated logo in the top bar DONE (using a higher DPI image)

Solutions

• Will probably just take new screenshots at x2-x3 current size by zooming in the browser.

Maybe it's a matter of opinion, but I prefer to avoid seeing expired pages when pressing the back button on the browser. In the Review Summary case, going to the second page of review statistics and then pressing the back button won't work as desired.

From @tbrams via email.

A layout I would vote for would have a button as big as your "Flip Card" button (that is not really needed, since you can just click on the card like you would expect on a mobile phone ^_^), instead of having a tiny button right next to "End".

Issue
Presumably, for mobile users some of the top buttons would be more easily accessible at the bottom of the screen (portrait). If the user often wants to lookup story or dictionary, it would be easier with buttons close to the thumbs? (question marks because I won an iPad and no smartphone >_>)

Considerations

• Story is probably the most often used of the top buttons
• "Exit" at the top is OK because it is secondary, and even better to be out of the way
• If we remove the top button row entirely, we could find some better layout at the bottom

Quick mockup (incomplete)
I did a quick mockup only to realize this won't work when you flip the card but here is some ideas:

• "Flip Card" is a subtle transparent overlay on the card, which actually doesn't do anything because as tbrams mentioned you can tap the card to flip anyway, but it is there as a hint, thus freeing the space at bottom
• we probably want the answer buttons to be bottom-most (unlike this mockup)
• if we move the meta data (strokecount and framenum) somewhere else.. we could use the same overlay idea to overlay "story" and "dict" on to the card..

Tagged discussion for now.

Tagged nice-to-have because it's not critical, but definitely something that is important for mobile users.

It was recognized that the Restudy & Learned UX, currently seen in the sidebar on desktop, can be logically merged together for a more logical flow.

• User "Starts" a restudy session, taking them to the first failed card
• User adds one or more failed card, each time "Add to learned list" is clicked, user is taken to the next failed card
• User selects "Clear" to cancel the restudy session, or "Review" to proceed with the SRS. Either way, the whole list is cleared

To be updated. Working on this!

The Vote / Copy / Report buttons on Study pages work better now due to the viewport set to 1:1 on mobile (ie. everything is a bit larger, and users don't need to zoom in).

Feedback from @rinre on previous forum:

I agree with toby, they work much better on the staging site. I tried it out now, and I find hitting the star is easy, but when hitting “report” I tend to hit the star instead (1/3 times or so). Perhaps a tiny bit more spacing between the symbols would be enough to improve this?

Solutions

• Increase the tap target and / or spacing
• Refresh the icons with FontAwesome or SVG, which also solves pixellated / blurrines on Hi-DPI screens

Thanks @tbrams.. didn't notice that the buttons collapse in 2 rows as soon as you add enough cards...

I remember discussing this on Google Group earlier. We agree that it was not necessary to repeat "cards" in each button, but we may need to remove the text altogether and use just numbers.

Or maybe I can get away with just normal font weight, and reduced padding.

(Moving to its own issue from #40 per @fabd request)

Keyboard navigation throughout the menus

An usability problem (well, more like a not-very-annoying-inconvenience-I-can-totally-live-with) is keyboard navigation throughout the menus. I don't remember when it happened exactly, it's been quite a while, but since the last menu revamp I no longer could logout by using just my keyboard.

I only noticed because I tend to use keyboard shortcuts/commands/navigation for everything I use regularly, not for impairment reasons, so it never was a real annoyance to reach for the mouse or touchpad. I have to do that anyway for other actions in the site for which using just the keyboard is impractical.

(...) just being able to reach all items by pressing tab would do.

SRS Reviews

That said, the SRS reviews work wonders in this respect (though I wish there was a keyboard shortcut to open the card's statistics -- the one you open with the hamburger icon), and I don't think implementing keyboard navigation thoroughly across the site will be worth it (unless an impaired user states otherwise).

Study pages' navigation

with the keyboard. I don't really know: a "too obvious" keypress would likely be triggered most of the time by mistake (inadvertent users), while a too complex combination would be hard to trigger for impaired people, precisely the ones who should benefit more from it; also, it shouldn't interfere with history editing, which can be hard to pinpoint right.

Open discussion for brainstorming ideas.

The home page for logged in users shows a kind of summary of the user activity and is meant to make it easy to find out what to do next, and to get an overview of the available content.

• Restudy link could do the same as clicking "Start" in the Restudy bar (work in progress), immediately starting a restudy session

• Blog... unless I add some notification system, it can stay as bottom content out of the way, or it could be summarized on mobile as headlines for the last X updates (doubt it improves loading speed though it could reduce requests when news posts contain images).

There it is.

You can file a bug report or suggestion.

You can @mention someone so they get pinged in their notifications.

You can also just drag and drop images it seems!

Currently using font based icons. This is very inefficient since the font contains hundreds of icons and we only use a small set of them.

• Experiment with Font Awesome 5 Pro SVG icons (currently at "5.0.0-beta5" release)
• Update inventory of icons in use & find matching FontAwesome 5 SVG icons
• Request feedback from mobile users (staging)

For a better experience without the browser bar.

A first implementation doesn't use any fancy cache or "service workers" if possible. All it does is make sure the app icon launches the app without the browser chrome for slightly more screen estate, and ensure the user stays within the app instead of being sent to the browser.

Issues

• Most links in the app take the user out of the app and open the page into the browser.

Solutions

• add a handler on the document root to prevent default link behaviour and change the document url via Javascript. I haven't tested this and there may be other issues, I don't know.
• would Turbolinks help with this? I assume as part of the functionality they already handle the links (ie. intercept standard links and use javascript to set document location).

Also requires #2 for the app icon.

The login page on staging comes with its password field prepopulated by default with a value equals to Password. Shouldn't it come empty?

Fix layout for long keyword

Issue transferred from the Google Group, screenshot from Ernir.

• Stories content may eventually extend edge-to-edge on smaller screens
• Ensure the meta info (stars, public status, etc) collapses below the keyword so no overlap
• Make keyword wrap
• ... also clip the content (in case of a long string of kanji/kana that doesn't word wrap)
• Reduce keyword font size?

When using a normal (1080p for example) display without any scaling in Chrome (or any other browser) or on the OS, the logo has to be scaled down, causing it to appear slightly blurry. This isn't a huge issue, but I still believe it should be fixed.

Here is an example of the difference between vector graphics and a PSD (rendered out as PNG) made with Inkscape:

And here are some links to the source files:

• raw (may have issues displaying fonts
• pathified (no render issues)

This is about the navigation menu for mobile

...also called "Off canvas", "Side Nav", "Slide Out" etc.

This issue will probably remain open for gathering general ideas / tweaks to the mobile menu.

• Do we want a "Home" or "Blog" in there? Currently the main logo in the top bar takes users to the home screen. It may not always be obvious, but it saves the extra space taken inside the menu.

• Top Level > Second Level> Menu items. NO. I preferred to avoid this. For example Flashcards > Manage could break down into Flashcards > Manage > Add, Remove, etc. This causes one more tap every time you want to navigate to those pages, as it explicitly moves this navigation between the Manage pages to the mobile Menu. Instead the current approach is to put what is the sidebar navigation on desktop, to a "table of content" style navigation for mobile.

Purpose

This issue is to collect accessibility related feedback. If any concrete item comes up I will create separate, actionable issues that can be closed.

Lighthouse

@magnonellie brought to my attention contrast issues that are detected by the Google Lighthouse tool.

As of writing, I am going to label this "nice-to-have" because some of the suggestions seem silly or fairly inconsequential. We also have to account that the audience is learning Japanese... so I assume if they can read kanji they can easily see the following items:

• the news date is a dark brown on a light cream color, pretty visible, it's bold text too
• the twitter button text is white against a saturated blue, pretty visible
• the green "push buttons" on the Home screen have white against a saturated green. This is a contrast of colour hue, but also brightness

/* "Elements must have sufficient color contrast (Failed on 13 elements)" */
#home-qs > div:nth-of-type(1) > .box.padded-box-inset.mb-p50 > .hd > .failed
#home-qs > div:nth-of-type(1) > .box.padded-box-inset.mb-p50 > .bd > .btn.btn-lg.btn-go
#home-qs > div:nth-of-type(2) > .box.padded-box-inset.mb-p50 > .hd > .expired
#home-qs > div:nth-of-type(2) > .box.padded-box-inset.mb-p50 > .bd > .btn.btn-lg.btn-go
#home-qs > div:nth-of-type(3) > .box.padded-box-inset.mb-p50 > .bd > .btn.btn-lg.btn-go
#sitenews > dl > dt:nth-of-type(1) > .newsdate
#sitenews > dl > dt:nth-of-type(2) > .newsdate
#sitenews > dl > dt:nth-of-type(3) > .newsdate
#sitenews > dl > dt:nth-of-type(4) > .newsdate
#sitenews > dl > dt:nth-of-type(5) > .newsdate
#footer > .k_bg_free > .container > section > p:nth-of-type(2) > a:nth-of-type(1)
#footer > .k_bg_free > .container > section > p:nth-of-type(2) > a:nth-of-type(2)
#ft-tweet_btn > a > span

As discussed in gitter, there are several possible enhancements we can talk about:

• Add a 3d effect to this chart's bars, like the ones in the leitner boxes.
• Implement one of several options to avoid the overlapping of the labels on very small screens.

Note: discussion issues are indefinitely open to gather general feedback on an area of the site, and I will post in those also to document smaller changes that happen on staging.

Updated on staging

• My Stories: simplified the intro text. Removed mention of "mouseover" for the hidden kanji (I geuss desktop users figured this out, and it needs to change for mobile), formatted stats in a compact way like the SRS page flashcards summary.
• My Stories : also extended stories edge-to-edge on small screen (++horizontal space)
• General styles : minor tweaks to the headings colour, I think it looks nicer (headings and main body text were the same black-ish colour, lacking contrast)

The documentation (aka "Help" in mobile nav) is completely outdated (has been for years, sigh).

URL in question : http://staging.koohii.com/learnmore

Copy editing

• Needs summarizing
• Rewording to avoid mentioning "clicks" or "mouse" unless really necessary (to keep things simple because I don't want to handle 2 documentation pages!)

Structure

• Find some way to break it down (maybe a Vue JS component here that would collect sections then display them one at a time via expand-collapse)

Pictures

• Needs up to date pictures, potentially higher DPI too

Navigation

• Use fixed to top navigation on desktop (sidebar doesn't scroll)
• Find a way to browse navigation on mobile (switch between views / sections ?)

Since I optimized the Search, Restudy & Learned sections of the Study sidebar for mobile, the sidebar looks rather lame on desktop.

Issues

• the Restudy red box is ugly and needs to be less contrasting, some users may knowingly leave some failed cards in there for a while, and this could be annoying
• lots of empty space due to simplifying and removing the Restudy "quick list".

Solutions

• a good enough "fix" for this is to just make the sidebar look nicer on desktop

A more advanced solution is to figure out in what ways sidebar could improve desktop experience. I don't think just adding stuff there "because we can", is a good UX improvement.

Brainstorming

• a "recently visited" list (last 10 browsed kanji) however is something Ive thought about and this could be a great use of the sidebar (on mobile potentially as a expand collapse somewhere)

For small screens the images get scaled down and look blurry on higher DPI screens.

Sites like Dropbox get away with that because their illustrations are quite simple and "crayon" like so they scale down fine.

If I use x2 images then they get scaled down on desktop and would look a bit blurry too.

One solution was to use a 320-360px image so it does not scale down on most modern smartphones, but on desktop it looks just a little too small...

Using pure html / css would be a solution. Or maybe even SVG ?

I'm spending way too much time over this, so it's a nice-to-have until I hear more about it. I assume that visitors understand this is an image and the actual pages are not blurry.

The paragraph above the Back button has a broken link pointing to http://kanji.koohii.com/review/flashcardlist. Should link to http://kanji.koohii.com/manage/flashcardlist instead.

The text summary columns seems to be squashed with lots of extra white margin to the right of the buttons.

Not a biggie, but @fabd, you might want to consider renaming the "Progress chart" button to simply "Progress" and giving the text column more space?

This is a big topic for brainstorming. Will create separate issues for actionable items.

Something I tend to always forget because I never see an empty state account.

Known Problems

• Progress Chart confusion: I think users often hit the "Progress Chart" first because it was the top most / left most link in the home page (after signing in). The chart would have links to "Test" lessons. Then user would be confused (and send me an email once in a while) because their progress did not update. --- These Test links were added as an after thought, a way to repeat lessons indefinitely. Test links have been removed in the mobile update to remove this confusion.

• Communicating to the users the difference between what I call "free" (indefinite) reviews and scheduled reviews is not easy. I haven't settled on definite wording for this. Example: "Kanji Review" and "Vocab Shuffle" pages. "Kanji Review" addresses this a little bit with an info box at the top stating "Review modes below do not use Spaced Repetition (SRS)."

• Lack of clear "STEP ONE" for a new user on the Home page

The Home Screen

Related discussion Improve the home screen content (logged in homepage) #7

Progress Chart

• Progress Chart empty state : first lesson says "Not yet started". Add a link there : "Start" that takes the user to the Study kanji #1 ? (this assumes Progress chart is the first thing they go to)

There is no highlight of the wrong / missing form fields.

On mobile it's an issue because the form fills the screen and the red box with the errors at the top is not super obvious (it seems non english users in particular have trouble with this, as they don't understand the message which is not visually connected to the corresponding input, especially "Invalid answer to the security question").

Solutions

• add an error state to the form fields, use Bootstrap .has-error
• display the error message below the concerned input (new class has-error-msg)
• on page load focus the first invalid fiel, this should scroll on mobile to put the field in view

From Ozar

I'm finding it's no longer possible to study individual deck piles (i.e., only due cards under 5+, 6+, etc.) I'm using Firefox 50.1.0, is this working as designed?

From Don

I am in the habit of reviewing my daily kanji starting with level 8 and then working downward to the lowest level. That ability is gone now. When I click on the orange review cards for each level, I am not able to review the kanji for that specific level. (...) If there is an easy way to restore the ability to review cards by level, I would really appreciate it.

From Craig

When reviewing, it was nice to be able to click on each stack individually, rather than have them grouped together as it is now.

From marc

I only miss the possibiliy to learn separatly every level of my kanji (is was possible in the old version).

I'm not sure I meant to remove it. Although I wasn't sure people used this, so I forgot about it. Mostly it is an oversight after refactoring the bar chart.

Solution

Pretty simple, the bar chart is HTML so the due piles can be made clickable. Either by wrapping an < A > tag or handling via Javascript.

The Leitner bar char on the Review page is cramped on mobile.

The solution originally planned was to summarize the info in fewer boxes for mobile view, so eg. Instead of having bars up to 7+ reviews, it would go to 5+; combining the last 3 boxes into one. Which is probably enough info for most users.

While it does kind of work now if I removed the "Fail & New" label to fix the overlapping text, it still looks a bit cramped.

Solutions

• extend the shaded box content to edges to gain a little bit of horizontal space
• reduce number of boxes in the graph, group box 5-6-7 into one.
• use horizontal bars, so label and bars can be stacked top to bottom. I preferred the vertical layout.. but hmm.

Tagging nice-to-have and discussion for now as it's not critical for public beta.

Use a common "Story" component between SharedStories lists on the Study page and "My Stories" list used on My Stories as well as 's stories (list of stories on their profile).

Goals

• the old code for vote / copy / report is a headache to maintain + its buggy
• will allow to ditch YUI 2 dependencies used for the fade in / out effect, use VueJS transition instead
• will allow to add a small animation after a star (eg. a small absolute pos. div that shows a rising star briefly)
• will allow to show confirmations with Notification or Message improving feedback on both mobile / desktop

There are loads of things I don't really need from Bootstrap, and I don't want to use in the future because it create more dependencies.

Currently the website mainly uses: reset, grid, base typography, forms, buttons.

The first four are basically the most vital elements I benefited from using Bootstrap in the mobile / responsive update and not much else is needed for reasons explained below.

Solution

As of writing I don't know if it's worth building Bootstrap vs just making a custom package from their site since I don't plan on using it more while transitioning to Vue JS components.

Random blabbering

Later I may switch to Bootstrap v4. I have to look at Bulma as well and the Vue-Blu component kit.

It's hard at this time to find a solid Vue Js 2 component kit without too much dependencies. The Bootstrap based ones are quite bad as far as I have seen, which is why I don't want to use more of Bootstrap styles.

Besides in general the styles are quite simple, such as the Panel, in which case it's better to have standalone styles in the vue files, without the CSS framework dependencies. I couldn't even use the Bootstrap nav for the navigation in desktop view, because it didn't quite behave the way I want to AND the way it handles the mobile navigation was too restricting. Besides we now have a mobile nav made from an instanced VueJS component, so the Bootstrap nav was of no use.

Since Vue 2 is still relatively new it means I can't use a single Vue 2 component kit because they all have their quirks and problems. So I hand pick some simple components here and there that I can build on, and that further emphasizes why we don't want dependency on a single CSS framework.

Basically the key to manage this site the past ten years, is to always consider what dependencies I have. Keep the css organized in a "component" fashion. All the styles applying to a given area or reusable component are lumped together. When I refactor, it's much easier to drop big chunks of CSS because they don't depend on a complex cascade. With .vue files it's even better as styles can be kept in the Vue file, ensuring we can replace plug in components, or replace them as needed without having all kind of side effects.

The Study search auto-complete UX needs to be improved on mobile and desktop. It's tiny and ugly.

AND it needs to be refactored completely with a VueJS 2 component (#114), The current code is extremely old Javascript that was made to work on IE6...

• Pass to the component the data from the RTK 5th / 6th editions Javascript added in the page by the backend based on the user's choice of RTK edition (we can't bake the auto complete data into the component itself, unless we baked in BOTH RTK edition indexes, which is not a big cost in terms of delivery size... but seems like the wrong solution if adding other indexes cf. #70 )

• Increase row height (tap target), font-size for mobile & touch

Can't just fix layout, need to redesign the sort UX.

One solution would be to use a dropdown for the sorting index, taking much less space. Since sorting index is not something that needs to be changed a lot, a dropdown sounds good.

Components

• MyStoriesList
• MyStoriesListItem ( PublicStory base component to use in SharedStories? )

Solutions

• Remove tags just use a click handler on the container
• Makes it much more easy to adapt the layout
• Replace "onhover" with a touch compatible tooltip
• ...

On my iPad Air 2 there is often a really long lag, half a second or more, you can see the progress bar is at just 10% or so, and there is the loading spinner, and the page is blank! Horrible delays on page load for staging on iOS Safari >_> makes no sense. It loads just fine on desktop. Safari even crashed once, what the hell is going on?

On staging Google Analytics is not enabled, so it's not that.

The page is blank, so it suggests it happens before the content, and before the YUI 2 / VueJS dependencies which are loaded later towards the end of the document.

I don't know how to pinpoint this on the handheld device. But it could be a good idea to cache FontAwesome anyway, so maybe we can use our own cache setting.

Solutions

• deliver FontAwesome font from the koohii server, see if it makes a difference
• figure out how to create a minimal build of FontAwesome with selected icons (we probably use less than 5% of all those icons!!) ... or just postpone this till we use SVG instead #16

Signing in to any website without a secure connection isn't a good thing. Google are planning to present users with a red warning sign on all sites that are not on a secure connection in the future.

There are two alternatives here as far as I see:

1. Buy a certificate and use that
2. Configure Let's Encrypt with the website

Buying a certificate is slightly easier but using LE is cheaper and can be really handy when you set it up to renew automatically.

Landing Page (edit: and "Register" page) shouldn't need to include "yui-base.js".

Pretty much the only reason it's there is that desktop view has a small drop down menu in the top right with "Sign In" "Register" (same options as the mobile nav).

We're far from being able to remove the legacy Javascript it's used throughout all the site, but if we can remove it from landing page it's worth it because that's the performance for the new visitors page , so this page should load as fast as possible.

Solution

Remove the dropdown menu for landing page + desktop, and just put "Sign In" there. "Register" is availabe further down the page. Worst case, just add "Register" also in the top bar next to "Sign In".

Adding an issue because I need to update live !!! And this isn't critical.

Include high DPI favicons

In particular because we want eventually to allow "Add to Home Screen" for a better mobile experience.

• Use webpack build? Bundle your favicons with Webpack

• Design a better icon

IMPORTANT: a better solution would be to use SVG icons #16

I use such a small portion of the icons, it would make sense to optimize the font.

• Use IcoMoon?
• Update the PageSpeed report: #23

Cons: rebuilding whenever I find a use for another icon.

Pros: I suspect the FontAwesome CDN causes a lag when I access staging on iOS, so hosting the optimized font may also address #32

https://blog.webjeda.com/optimize-fontawesome/

This is the single most painful piece of legacy code for me to look at.

It's incredible to think how much easier it would be to develop today with Vue JS.

Countless times I've thought about some simple features, like adding example words to flashcards, and I can think of how straightforward this can be done with Vue, but it would be a nightmare now to continue to do it with DOM manipulation.

It's not incredibly difficult to rewrite with Vue, but a good chunk of work to be done in one piece.

Maybe it's on purpose, but there is no link pointing to the forum for not-logged-in / anonymous users. Perhaps it would fit in the footer (or even as one of the showcased features).

I know there are more not linked "facilities" (like the wiki), but the forum seems like something to promote from the main page. Just my two cents.

ファブリス,

Would you consider keeping the 3D look for the leitner boxes on the desktop site and have it shrink down to the flat 2D bars for mobile? It's picky I know but I feel the 3D look makes it feel like a physical collection of cards piling up which is a bit more motivating for me than the flat 2D bars currently on the staging site, that seems like a statistic on a bar chart rather than an indication of progress that has depth....sorry flat design purists.