rgrig / javadoc-reader Goto Github PK

The upper-left source selection should be a drop-down that allows the user
to easily select popular APIs. Free form text should still be allowed.

Make the back/forward buttons work as expected. I believe this will also
allow bookmarking.

The default package ("") can't be represented with the current format
(server->client) for the index.

Also, when concatenating with the class name there'll be a '.' in the
beginning.

Perhaps other places are affected too.

Allow searches with wildcards. The design needs to be discussed.

The url http://java-api.appspot.com/ should work without adding ui/Main.html

Allow full-text search using Google (perhaps programatically). The
interface needs to be discussed.

The top results should appear in a suggestion box. 

'Top' is of course subjective. It should ideally be based on a combination of
(1) how popular the class/package is
(2) how close is the match

For (1) we need to keep statistics on the server.
For (2) we need to give a better score to Exception than to BlaException if
the user typed "Exception". Not sure what heuristic to use.

Pressing enter in the suggestion box should go to the web-page of a
class/package if there is a perfect match.

The suggestion box should be updated cca 0.2s after the last keystroke. The
long list should be updated (1) when enter is pressed and (2) cca 1s after
the last keystroke.

It would be nice if we could increase the displayed results as the user
scrolls down. 

I first heard about this technique in a tech talk by Aza Raskin
(http://www.youtube.com/watch?v=EuELwq2ThJE). At around 22mins he talks
about "the river of news". 

Google reader does something similar for loading additional items as you
get near the bottom of what is currently shown.

Motivation: reduce clunkiness and number of clicks required from users, but
still allowing us to show a smaller number of search results initially.

Difficulties: how to deal with different categories of results
(packages/classes).

It should be possible to search the full text. A simple solution is to
fall-back to Google. Another (perhaps not doable) is to implement an index.

The "title" attribute differentiates between more categories than just
classes/interfaces. We should just have one class Unit and an enum that
indicated its "type".

The user experience must be imrpved. Possible improvements:
1. Cache the class lists on the server.
2. Print the first MAX_RESULTS classes while loading the page in background.
3. GZip the list of packages/classes.

Tweak the css.

It should be possible to search for method names.

The most important usecase is
1. user opens the browser
2. types part a class name, perhaps almost all
3. presses enter
4. user wants to see the proper doc

Users often make spelling errors, for example by swapping letters or by
typing nearby letter. We should cater for that.

It used to take 200--300ms with arrays and now it takes 700--800ms with
ArrayLists. It must be <250ms.

It would be nice if the user could select a *set* of javadocs he wants to
search simultaneously.