fabd / kanji-koohii Goto Github PK
View Code? Open in Web Editor NEWA web application to help Japanese language learners remember the kanji.
Home Page: https://kanji.koohii.com
License: GNU Affero General Public License v3.0
A web application to help Japanese language learners remember the kanji.
Home Page: https://kanji.koohii.com
License: GNU Affero General Public License v3.0
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
The "unhide" solution for controversial / adult themed mnemonics is less than ideal. By suggesting something is hidden, it makes you want to "unhide".
Breakdown
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
Solutions
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).
Labeling issues like this design
which could potentially be taken up by someone with the skills!
See related "Use SVG icons" #16
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
uISelectTable
backend component. (keep the data in the backend for now, and let the backend do the paging)
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
Solutions
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
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:
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.
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
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)
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.
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).
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.
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.
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?
Issue transferred from the Google Group, screenshot from Ernir.
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:
...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.
This issue is to collect accessibility related feedback. If any concrete item comes up I will create separate, actionable issues that can be closed.
@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:
/* "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:
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
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
Structure
Pictures
Navigation
Since I optimized the Search, Restudy & Learned sections of the Study sidebar for mobile, the sidebar looks rather lame on desktop.
Issues
Solutions
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
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
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
.has-error
has-error-msg
)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
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
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
Components
Solutions
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
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:
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.
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.
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
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.