Cache gets confused when it saves the requested information (e.g, verse 7) along the the entire chapter. A later request may want a different verse or no verse.

Currently edit/translated options only exist in #about menu at the top of page. When you're scrolled down a page this is inconvenient.

"Edit Text" option should always appear. Bonus points if selecting "Edit Text" on e.g., paragraph 5 will scroll to paragraph 5 once opened for editing.

"Translate Text" should be conditional on text existing in Hebrew but no in English.

I recently created the book "Aruch HaShulchan" and I accidentally created the "text structure" incorrectly such that I only have 2 levels of structure instead of 3. However, when I navigate to "Edit Text Structure" I am not able to edit the "text structure" regarding levels.

Add a feature to share a source-sheet with a collaborator who can also make edits to the sheet. This would be akin to Google Docs' ability to share documents with someone who "can edit."

I usually work with a partner on source-sheets and such a feature would be pretty useful.

Nothing appears to happen when clicking a revert button.

error: texts doesn't pass validation.

When I choose to make a source sheet either fully English or fully Hebrew, my preferences are not saved when I return to the source sheet. The sheet always appears in bilingual format.

Currently no indiction of success or failure after saving a new version.

• Should land on the new version with a succes message.

dragging happening with iScroll in the div, not sure when event to bind on.

Need a method to authenticate without leaving the page. This is particularly important with the Source Sheet Builder, which allows you to start building a Source Sheet without logging in, but only allows you to save once you're logged in. This means currently there is no way to save a source sheet that is started when logged out.

From the about menu of any text with multiple versions, add a "Compare to" menu which allows the user to select another version.

Show both versions side by side similar to the bilingual view.

Should change top left buttons into a compare mode (lang controls don't make sense in this context, but layout might) which an option to exit compare mode or choose another version.

Looking at a page like http://www.sefaria.org/Genesis.1 in Google Chrome 21 and Opera 11.6, the last of the sources are truncated at the bottom of their pane.

We current have a text history page for each lowest level segment. A summary page for the next higher level would allow clear linking from the reader to the a history page for that complete chapter / daf.

When adding a source to a source sheet users can specify arbitrarily high end verses which are then recorded on the source-sheet. For example, I can specify verses: Genesis 1:1-1000. I get all of the first chapter of Genesis, but with the header "Genesis 1:1-1000"

• UI in header to enter full edit from line edit
• Prompt for a choice when dealing with text fragments
• Track changes to segment breaks, send whole text

When copying sources from public source-sheets there are a few bugs:

1. Any additional text that has been added (such as English translation) or deleted (such as when the creator deleted extraneous parts of text) are not copied over.

2. Formatting is not copied over (probably the same fix as 1)

3. Some sources that I tried copying just appeared with "undefined" in the text boxes. This seems to be a sensitive bug since when I tried again the behavior was as normal.

I was playing around with the page for editing the texts and I noticed that if you click a label for the verse, the + button for verseControls appears in the middle of the screen, haphazardly. This probably should not be the case.

E.g, for a text like http://sefaria.org/For_the_Perplexed_of_the_Generation.2

when editing the english in a bilingual mode, the english is much shorter, causing sync problems.

I believe this can be fixed by just increasing the hebrew text size here.

Would it be possible to add the ability to change size formatting for sources? I see this functionality useful in a few ways:

1. When copying text into Sefaria sometimes the sizes dont match.
2. Many people like de-emphasizing certain parts of sources by shrinking their size while still keeping the entire source on the source sheet.

(Note: Perhaps this would be better for a google groups discussion - not sure)

While I appreciate the semantic and sectional divisions provided by sefaria, many times I only want to use a section of a source, a fragment of a gemara, or 2.3 mishnaiot. This is especially true for gemara sources where my sources rarely fit into a predefined semantic block. To that end it would be great if I could add to a source sheet by simply highlighting the fragment I am interested in and clicking (right clicking?) to add to a source sheet.

One issue related to this is how to copy over the corresponding translation. I suggest a greedy method of copying over translation to ensure that the fragment is covered. For example, if I take a fragment from the end of verse 1 through the first half of verse 2, the translation for the entirety of verses 1+2 should be copied over to my source sheet.

No "Edit Text" button appears, not sure why.

Also can't edit Can't edit http://www.sefaria.org/Shulchan_Aruch.1.401

We need to know more about the texts we have and the texts we need. This involves a few sides:

1. Knowing information about the size and structure of text in general. E.g., knowing that Bereishit contains 50 chapters and that chapter 50 of Genesis contains 26 verses.
2. Knowing summary information about the actual texts and translations we have in DB. E.g, being able to say, we have 100% of the the Hebrew of Bereishit across 3 versions, but that we only have 35% of Mishna Peah in English. This information may be summarized across all the texts we have.
3. Knowing information about a particular version of a text. E.g., verse for verse knowing whether and by whom a text has been reviewed, or storing ratings for the quality of a particular translations on a segment by segment basis.

Collecting information in (1) maybe be just as difficult as actually getting the text (e.g., counting precisely how many Rashis there are on which dafs of gemara). Handling incomplete information will be a requirement. Being able to provide estimates for sizes will be very helpful for estimating the magnitude of our task.

Load the next section of a text below the existing when scrolled to the bottom of the page. This would be easy except it will involve reviewing and refactoring many assumptions about what the current text is (what should sjs.current contain?) and the way that segments are connected to to commentary.

Having this work would allow next / previous buttons to scroll vertically instead of horizontally, which makes a clear UX distinction between moving within a particular text (vertical) and jumping across related texts (horiztonal)

Akin to http://taggedtanakh.org/Chapter/Index/english-Gen-13 when you click "Book", across all kinds of texts

• Call server to find chapter counts / names
• Requires knowing section counts

A sensible point system tracking contributions will help us to identifying trustworthy contributors and may motivate participation.

The simplest version of this just counts the number of activity items per user in the history collection. This could be easily gamed.

The question is, what are the relative values of the following actions:

• adding / editing a new segment of text
• adding / editing text info for a new text
• adding / editing an original translation
• adding / editing a new connection
• adding / editing a note

Quetions:

• Should the length of text added / editing affect points or is each segment equal?
• Should the depth of an edit affect points or are all edit equal?
• Should we doc points when an edit is reverted? or for other yet to be implemented signals that contribution is not good.

When you navigate to "Edit a Text" the two buttons on the bottom of the screen allow you to either "Save" or "Cancel"

However, if you decide to do neither and instead try to navigate to another text (by typing in the search bar, for instance), you get a nasty mashup fo both screens overlaid.

Fix:
If the user navigates away from the "Edit a Text" screen, Sefaria should handle that move cleanly. If the user has actually modified any information in the text without saving perhaps Sefaria should prompt the user asker her if she wants to save her edits.

• correct link gets saved, but the snippet shown is incorrect (like a +1 issue on verse num vs array index)

In reader UI, a chance to the JS broke this.

Currently sheet URLs and and URLs to contributor pages contain system-generated IDs e.g.
http://www.sefaria.org/sheets/20
and
http://www.sefaria.org/contributors/dp9hy7KKpgXJF_uJTNryhePAs883hy.

Changing both of these URLs to a RESTful format will improve both usability and discoverability (SEO) of the content. For sheets, the URL should include the sheet name; for contributors, the URL should include the contributor name, e.g.
http://www.sefaria.org/sheets/The-Spice-Of-Life
and
http://www.sefaria.org/contributors/Yehoshua-Kahan

Perhaps characters outside of the normal URL characters can be handled by the same rules as WordPress.

• UI for gathering name, name variants, sections names and counts, categories
• Requires creating a new document in "indexes"

Due to my own ignorane of best practices, Sefaria has no tests. I'd sleep much better at night if we did. If anyone with more experience than myself wants to get the ball moving here it could be a great help.

Publicly credit top contributors (based on a point system or simple count of activity items). Show top contributors by week / month / all time.

Each page in the reader currently loads with an embedded JSON which is used to generate a view client-side. Generating markup server-side is an important step for SEO and will improve page load times.

A half measure which still accomplishes the SEO goal is to generate dummy markup with the content, but still rely on the Javascript to regenerate the actual markup used in the app.

1. Drop down tab for "outside sources"
   On source sheets there is no drop down tab/arrow for outside source sheets. I am refering to the tab which allows you to "Edit Source Title", "Add Sub-Source", etc.

2. Translation
   Outside sources only are provided with a single textbox so there is no defined place to put translations. This is aesthetically challenging when making source sheets with side-by-side translations.

The experience in of adding a new source has a first approximation of this, but it's not very clean, reusable or reliable. What's needed:

• A text area for typing citations
• Suggestions for texts titles
• Feedback for the next info need to complete a valid citation ("Enter a chapter")
• When the citation narrow enough, showing the text the actual text and making it easy to choose a selection visually. (e.g., once I've type Yoma 12b, I should see the full text f the daf and then be able to select the correct line numbers)

Need to smartly collapses related activity items to avoid show redundant information.

• Multiple edits in a short period should collapse, mention multiples and link to history
• Adding e.g., an entire chapter of text should display one item for the entire add, not one for every verse.

• Link from activity page or text history to a user profile.
• Show a feed of their activity
• Show summary info (join date, number of contributions)
• Optional bio
• Will require setting a unique username for URL.

Not currently distinguishing between Hebrew / English

• List versions in About Text modal
• need to be able to request unique version from the backend

Sefaria doesn't currently support IE of any version. The reader app will give a warning to IE users and ask them to try Chrome, Firefox or Safari.

Any PC users out there could us figure out a strategy for addressing IE support (whether its looking at individual bugs or higher level approach)

Categories which don't fit into the hierarchy don't properly get added to an "Other" category in the texts menu. Sometimes the unknown category will appear duplicated. Problem is in update_summaries_on_change().

Solved by rebuilding text menu from scratch with update_summmaries().

It would be nice to have an easy way to flip from one Chapter to the next (or even from Book to Book). At the very least though, if I'm browsing Tanach, I should be able to go from (e.g.) Genesis 2 to either Genesis 1 or Genesis 3 easily.

Maybe, in addition to the forward/back buttons, there could be similar buttons on the bottom of the text to go to the next/previous chapter?

Currently, page URLs don't change when moving from the view mode to an edit mode. Tracking these states in URLs would make it much simpler for different apps (like source sheets) or code within the app to route towards editing.

/add/Kohelet.4 - an open text area for adding a version of this text
/edit/Kohelet.4/en/Sefaria_Comunity_Translation - edit requires specifying lang and version title
/translate/Kohelet.4 - Hebrew text presented next to an open text area

Requires:

• routing state changes to edit modes through History.pushState()
• URL routes that inject appropriate data into reader.html
• reader.js load checking what type of page should be create (view vs add, edit, translate) and responding appropriately

Load the next section of a text below the existing when scrolled to the bottom of the page. This would be easy except it will involve reviewing and refactoring many assumptions about what the current text is (what should sjs.current contain?) and the way that segments are connected to to commentary.

Having this work would allow next / previous buttons to scroll vertically instead of horizontally, which makes a clear UX distinction between moving within a particular text (vertical) and jumping across related texts (horiztonal)

After clicking "edit text" let each line be edited by clicking.

• Track changes (and display in header, e.g., "3 verses changed")
• send changes as a batch on "Save" click
• account for texts of mixed source

With a few @media queries and a little javascript, I think the basic app could be usable on smartphones.

• hide top right controls (language, format) under a single button which opens a menu, keep header to a single line.
• hide commentary pane entirely -- only show it after click on a segment.
• hide all editing features, stick to view only.

Responses of texts API needs to be cached. Tricky part is knowing when to expire the cache especially due to connections. The response for "Genesis.1" may need to be expired when:

• Its text is edited
• a link is added or edited
• the linked text is edited