The current implementation of title normalization is mostly right, but it probably still fails on some titles.
I already patched it in issue #7 but it's certainly still incomplete.
I should have the same rules as in https://github.com/evopedia/evopedia_qt/blob/master/src/localarchive.cpp
In particular, every non-alphanumeric character should be replaced by an underscore

Currently, if there are several archives on the device, the first one is selected at every startup.
It would be better to select the last used archive (if it exists), instead of first one

License of this source code + link to its description
For each library used : a link to its source code, and a link to its license

The user should find the same page as when he launched the application, with a welcome text, an empty search field, no results and no articles displayed

The RC1 is almost released, and it is said to be "mobile-first"

Probably based on l10n.js library : https://github.com/fabi1cazenave/webL10n
I should also read https://hacks.mozilla.org/2013/08/localizing-firefox-os-apps/

The results should be better separated, and be highlighted when the cursor is above (on desktop)
On desktop, using the arrow keys should let the user move through the results, as a kind of "auto-suggest" feature

In particular, the last sections of the articles are collapsed, to avoid too much scrolling

They lead to the First article starting with "File".
It should either be deactivated or lead to the referenced file.

It might be related to the experimental hidpi on this device

It seems not visible enough. Maybe simply outlining it?
If we simply put the focus on it, it will be naturally outlined byt bootstrap, and the keyboard would also appear

Or maybe center this search field in the page?
Some users were confused by the search icon on the right of this field, and thought they had to click on it before searching

Uncompressing an article is very slow on a device : usually around 5s on a Geeksphone Peak.

But I think this will be hard to improve.
Maybe another javascript implementation : https://github.com/kirilloid/bzip2-js or https://github.com/skeggse/node-bzip/blob/master/node-bzip/index.js
The bzip2 compression format seems to support multi-core decoding. On the Peak device, it would be useful (dual-core CPU), but I think that all these javascript implementations do not support multi-core decoding
A better way to optimize this would be to have a b2g API like https://wiki.mozilla.org/WebAPI/ArchiveAPI. But that does not seem to be planned by Mozilla for now...

Most of the hyperlinks will not work : the user should be warned about that

Example : in the French dump, in article "Phonétique historique", if you click on the link "modifications", it should lead to the article with title "Liste_des_modifications_phonétiques"
This article exists, but the search algorithm seems to skip it. Maybe an off-by-one bug

Ideally, it would be the standard buttons of the browser.
Like the ones that appear at the bottom of web pages in Firefox inside Firefox OS

If not possible, it's easy to add buttons with javascript that does that

Currently, the sdcard is scanned at every startup of the application, and the user has to choose which archive he wants to use.
This should be done only once : the selected archive should be stored on the device, so that the sdcard is not scanned the next time.
The user should also have a way to change the archive stored in its user preferences, in the "Configure section"

I would geolocate the device, and display a list of articles nearby.

The algorithm to search articles of an archive based on their location seems a bit complicated to implement, but it works on the Qt version of Evopedia
On this Qt version, the articles are also displayed on an openstreetmap map. But the issue is how to have the tiles without Internet Access?
For now, I won't try to locate articles on a map, just display a list of articles nearby

Currently, it's filled and emptied only by the user, manually.
Maybe after a click on an article, it should be filled with the exact article name. Or maybe it should be emptied in that case?

Example : title "Gestion_des_données_de_référence" in the French dump

Like an up arrow icon, that would simply lead to a #top anchor (or something similar).
And maybe a search icon, to directly start a new search?
Anyway, it would need to replace the anchors used for the article name by something else, like ?title=xxx

jQuery adds the support for Internet Explorer (9+), including (I suppose) the one on Windows Mobile.

Zepto supports all the other major browsers/devices, and is a bit faster and lighter.
Zepto is less tested with other libraries like Bootstrap. It also needs to be compiled with modules selector and data, which are not in the default version of Zepto.

It seems possible to install both, and choose jQuery only when using IE. But it's not in a require.js way (see doc of Zepto and below)

<script>
document.write('<script src=' +
('__proto__' in {} ? 'zepto' : 'jquery') +
'.js><\/script>')
</script>

Currently, webworkers are mandatory for the application to work.
It would become optional, and make the application work on browsers where webworkers are not implemented

It's certainly due to the fact that searches are asynchronous.
It probably happened after a quick click on an article, while another search was running.

A click on an article should probably "cancel" any running search (in the sense that the search results should not be displayed in that case)

As this step takes a long time (~5s on a device for an article), it should not block the browser.
The user feedback would be better (spinner icon turning instead of being stuck)

Example : "a" in the French dump

It's probably possible as the title search is pretty fast.

This would remove the "Search" button.
After each keyUp in the prefix input field, the title search would be launched in the background, to display the results in real time.

The current implementation uses the same search algorithm as the prefix search. It simply takes the first result.
While it works in most cases, it can lead to a wrong article when there are similar titles that are the same when normalized (with different accents for example).
For example, make a search with "ascii" in the French dump, and display the first article "Ascii". At the end of paragraph "Table des 128 caractères ASCII", there are links to the article of each letter. If you click on the letter A, it should lead you to the article named "A_(lettre)". But it leads you to the article named "Å (lettre)", with an accent on A.

It currently leads to the first article of the dump...
At the very least these links should be deactivated.
We should see how it is done in the original evopedia

With the standard look and feel
See for example https://hacks.mozilla.org/2013/06/building-a-todo-app-for-firefox-os-part-1/

Currently, on a mobile device, if you have the expanded menu, and click inside the search field, the keyboard appears and there is very little space left on the screen.
So the search results are not easilly seen.

Example : in the French dump, display the article "Lampassé". There is a link in the second paragraph with name "Léopard". The URL is "Lion_(h%C3%A9raldique)#L.C3.A9opard_et_L.C3.A9opard_lionn.C3.A9"
When you click on it, it gives an error "malformed URI sequence" in utf8.js

I suppose it comes from the strange encoding after the anchor
It works properly in the original application

Some users think the loading is not over because the first page is mostly white.
This welcome text could also give some directions for the first steps : download a dump, put it on the sdcard, type a prefix etc

It needs to be able to find the local archive corresponding to the language of the link
What to do if there are several? Maybe choose the latest one?

The error handling code is not very clean.
We sometimes test on the error message, which is very bad practice
We sometimes put the error message as the article content
We also call alert() from the algorithm, which should not have a dependency on the GUI.

I'm not proud of all this : it's not clean and not bullet-proof

It should only zoom the article content, not the whole user interface

When no archive as been set, it might be better to disable the search field.
Or at least display an error when the user tries to search.

It's a bit complicated for the end-user to download an archive separately (with a bittorrent client), then to put it on the sdcard of its phone. It might be a blocker for some.

An idea would be to put a bittorrent client inside Evopedia (as in the original application). The archive could be downloaded directly from it.
Maybe using http://btappjs.com/ or a similar library.

In any case, downloading all these GBytes will take numerous hours, and should be done through an unlimited internet connection (i.e. usually WiFi instead of 3G/4G)

In particular, after clicking on an external link, you have no way to go back to the previous page.
Maybe a simple window.open(url) might work?

Currently, you have to select each individual file separately, which is a bit annoying.
It would be easier to make the user select all the files from the archive directory.

In the code, it should be easy to recognize each of the files based on its name.
It would even be better to find the file names inside the metadata.txt file

It's caused by the current implementation of the readArticle function : it re-uses the prefix search, and takes the first result.
When the article can not be found, or if there are several with the same name (after noramlizing), you can end up on the wrong one.

The readArticle function should be re-implemented to lead only to the exact same name. And display an error if it is not found.

On the "small" dump, this behavior can be very easily seen, as most hyperlinks lead to articles that do not exist in the dump.

When clicking on a link where the title contains some special characters, it does not lead to the right article

On the French dump (2013-02-16), when searching for the "Mi" article (with an "i" without accents and in small case), the article can not be displayed : nothing appears on the screen, and no error message