[sword-devel] User Interface design for Tyndale STEP

David Instone-Brewer Technical at Tyndale.cam.ac.uk
Wed Apr 28 02:23:10 MST 2010

On the search dropdown:

I was thinking that there wasn't any need for the extra dropdown 
"Passage" between the Ref box and the binocular button.
I hadn't really thought about what was in the dropdown below 
"Passage" in your mockups.

Thinking about it, and bearing in mind what you say about not 
duplicating the side bars, I suppose this should give various ways to 
search the Bible text.

"Chapter / text"  looks up the passage and tells them that they can 
request either a whole  chapter or verse(s) reference.
"Exact word / phase"  is a straightforward concordance search
"Contain these words" looks for more than one word in any order
"Fuzzy search" looks for similar forms and spellings
"Similar meaning"  uses a semantic domain lookup, so if they search 
for "king" it will also search for "kingly", "monarch", "ruler" etc
"Strongs Number" - not really necessary cos we can use internal logic
"Greek / Hebrew" - not really necessary, but this reminds them they 
can use 'real' Hebrew & Greek
"Greek transliteration"  - it would be nice to have a pop-up table of 
equivalent letters.
"Hebrew transliteration"  - ditto

We might also want to add some tick-options like
* order in the Bible
* order by relevance  -  fuzzy relevance plus order by popular books first
* order by recent use - list first any chapters in the bookmarks

On the bookmark pane:
I liked your idea of listing different things here (Timeline, People, 
Literature, Maps, History) - ie anything specific to the chapters displayed.
Among that list could go "prev. chaps" (ie automatic bookmarks) and 
"bookmarks" (ie manual or private bookmarks).
It would be great to store the both sets of bookmarks, and (if we 
have some overflow scrolling, such as "^" at the top and bottom) we 
can keep the list going for a long time. That list would also be 
useful for working out "Order by recent use" and "Order by relevance" 
(ie it tells us what their 'popular' books are).

David IB

At 21:24 27/04/2010, Chris Burrell wrote:

>David IB, you said:
>* I think we could reduce the size of the search options by simply 
>having a dropdown from the binoculars. Most of the time, there won't 
>be any need to specify the kind of search, because a Reference, or 
>Strongs# is unambiguous, and we can set the default to a concordance 
>search for most other things. If they have the sidebar open at 
>People or Places we can change the default to that. So most of the 
>time people won't have to choose the search database.
>- Could you clarify which options we should see under there?
>- Where do we expect the results to go? (I think we want to avoid 
>replacing what we can find in the sidebar)
>I assume you were referring to putting the binoculars in the text 
>field, with a dropdown coming down from it? I think at that point we 
>need a button to say "Go". it can be a small button, but if the 
>binoculars initiate a dropdown, although the enter key will fire off 
>the search, a lot of users look for a button to press too.
> >>> Bookmarks:
>Do we expect bookmarks to carry on from session to session? Do we 
>expect all our personal bookmarks to appear in the bookmarks pane?
>On 27 April 2010 20:07, Chris Burrell 
><<mailto:chris at burrell.me.uk>chris at burrell.me.uk> wrote:
>- Tabs in the cross-reference box at the bottom: We could fit about 
>5 tabs in there... Or we could have several rows...
>- Good idea about the [-] option. we could have that in the box, 
>leaving the tabs at the bottom/top of the box.
>- in terms of the inline scrolling, how about using the page flow, 
>so long web pages, but the bits at the top and the bottom would 
>always be visible (so we're using the browser scroll bar, but always 
>have the header and bottom visible (like a status bar in a window). 
>Then the side bit can follow as it scrolls up and down, so it's always there.
>Possibly the next step is to create all those bits as features in 
>JIRA and come up with a working model, albeit with mock data where 
>we don't have something yet.
>Then we'll be able to play a bit with it and see how it feels.
>On 27 April 2010 13:49, David Instone-Brewer 
><<mailto:Technical at tyndale.cam.ac.uk>Technical at tyndale.cam.ac.uk> wrote:
>Dear Chris
>Yep - these responses sound good.
>A few comments:
>Tabs for extra views - I think the "bookmarks" already provide this.
>Unclicking tabs - people are used to unclicking a button or a 
>radio-button selection. Could the tab stand out like a button? But a 
>simple [-] or "off" would work too
>Inline scrollbars - I don't see what's wrong with these. They have 
>gone out of fashion on web pages but merely because Google doesn't 
>like frames.
>    - I much prefer an inline scrollbar to a long webpage, cos you 
> can't see everything at once. Eg, you might be looking at the 
> bottom of a chapter, while trying to read the top of a lexicon 
> definition, or a popout with a list of names, or the first verses 
> of a different chapter.
>Hover display - overlaying the search box and title sounds OK. I 
>agree the middle area is narrow.
>David IB
>At 13:13 27/04/2010, Chris Burrell wrote:
>>And few extra comments
>>+ To increase space allocated to seeing the passage, it would be 
>>good to be able to expand downwards
>>+ Mobile devices would probably default to one pane with a smaller 
>>set of icons on the side
>>+ A pin on the sidebar would allow you to collapse the sidebar 
>>further (using smaller icons as David Haslam was mentioning)
>>+ Someone mentioned workspaces/virtual desktops. My flatmate 
>>mentioned it as well. It would be good to find an intuitive way of 
>>saving the view, or creating a new view. So that users who want to 
>>see more than two panes can start flicking between their views... 
>>Maybe tabs on the top of each pane? or at the very top, a banner 
>>with a tab ( a bit like Google Chrome has)
>>On 27 April 2010 13:06, Chris Burrell 
>><<mailto:chris at burrell.me.uk>chris at burrell.me.uk> wrote:
>>My comments below, prefixed with >>> (and in bold if that comes through)
>>On 26 April 2010 13:00, David Instone-Brewer 
>><<mailto:Technical at tyndale.cam.ac.uk> Technical at tyndale.cam.ac.uk> wrote:
>>Chris, these are great!
>>(David, I've copied you in for your creative 'eye' - links to 
>>screenshots are 
>>* I love the tags along the top of the text panes, which don't take 
>>up much room and dropdown to list the versions
>>* I love the footprint logo at the bottom middle.
>>* The Tools menu at top right is a great idea.
>>* The big friendly buttons down the left are nice. They look a bit 
>>mysterious to start with, but are quickly learned.
>> >>> I think we can easily add some "alternative text" to let the 
>> user know what the button is in a non obstructive way
>>* The popout of People etc,  overlaying most of the text panes works well.
>>* The people list - starting with a list at Aaron, Abaddon etc, 
>>with "more" looks good as a quick way to pick the person you want
>>* The idea of starting typing and filtering the results is very intuitive.
>>* I like the idea of intelligence for searching, with the option of 
>>telling it what to search for. So if someone looks up Aaron, they 
>>can decide if they want the People database or a concordance search.
>>* the Bookmarks in the middle look perfect - intuitive, and don't 
>>take up much room.
>>* Using the space between the panes for "Timeline", "People" etc is 
>>a great idea. The "Bookmarks" could be simply one of them. - ie 
>>click on one, and it turns into a list of the People, Maps, 
>>Bookmarks etc which are available.
>>* I like the idea of Green as a colour scheme - it fits nicely with 
>>the logo and looks friendly.
>>* I agree we need a config page but it can be separate
>>* I agree we can use Browser back buttons
>>* I too have misgivings about menus at the top. Personally I like 
>>them, esp for providing keyboard shortcuts, but they make 
>>applications look dated. If we have it, perhaps it could be an option.
>>Some minor suggestions (most of them are further ideas which you 
>>may already have in mind)
>>* The bridge would look more intuitive if it touched both sides and 
>>looked like one of those bridges which lift up to let boats under 
>>(ie the connection between the two sides is broken)
>>  >>> Yes, I couldn't find a proper bridge like that. I think that 
>> a chain might be better (link / unlink). One of the problems is 
>> that the picture needs to be so big since the two panes are 
>> relatively speaking quite far from each other...
>>* We need some indication of what version we are looking at. - ie 
>>when you click on the dropdown for "English" versions and pick ESV, 
>>then pick KJV on the other pane, we need to see somewhere that that 
>>these are what we have selected.
>> >>> Yep, so perhaps something like Matthew 8:2-13 [ESV] in the title?
>>* I'd prefer tabs on the bottom boxes instead of an options button. 
>>This would indicates that all those tabs remain 'live' and 
>>available, and unclicking the one which is clicked could minimise the box.
>> >>> I'm not sure unclicking a tab is very intuitive? or are you 
>> thinking of having a tab called "No info"
>>* perhaps we could indicate "manual"  or "personal" bookmarks (ie 
>>ones which the user especially wants to remember) by highlighting 
>>them or making them a different colour. Or perhaps "personal 
>>bookmarks" could be a separate list.
>> >>> Yes, agreed. So part of the idea on one of the buttons (in a 
>> later screenshot) was to have a bookmarks option so that people 
>> could get to them very quickly when they come back.
>>* It would be nice to have to option of opening a box at the bottom 
>>of both text panes, even if they are linked, so someone could see 
>>(say) both crossRefs and personal notes at the same time.
>> >>> Yup. Good idea.
>>* I think we could reduce the size of the search options by simply 
>>having a dropdown from the binoculars. Most of the time, there 
>>won't be any need to specify the kind of search, because a 
>>Reference, or Strongs# is unambiguous, and we can set the default 
>>to a concordance search for most other things. If they have the 
>>sidebar open at People or Places we can change the default to that. 
>>So most of the time people won't have to choose the search database.
>> >>> Yes, although I don't understand the comment about when the 
>> side bar is open. The idea is to make the side bar a temporary 
>> helper to the application, which "disables" most of the 
>> application behind while open.
>>* Do we need a search box inside the side popouts? The main 
>>searchbox could be used. Perhaps the sidebar and popout could start 
>>higher up, so that the main searchbox could be incorporated into the popout.
>> >>> I think we do. I think it would confuse people if we only have 
>> 1: one of the search boxes is to carry out a one-off search, the 
>> other one in the popout is to filter search results according to 
>> what module is selected on the toolbar.
>>* Could we use the bookmark space for our hover-over information? 
>>I'd really like to avoid the usual problem of overlaying the very 
>>text you are trying to read.
>> >>> Good idea (although it's kind of narrow...). I was going to 
>> suggest using the notes field at the bottom, but that wouldn't 
>> work because of my comments down below. Another option is to use a 
>> overlay on the top header part (covering the search boxes)
>>* One of the trickiest things is typing a reference. Could we give 
>>the user some help? Perhaps, when they start typing in the search 
>>box, we could have an initial dropdown of Bible books (ie type "G" 
>>and get "Genesis 1... /  Galatians 1..." at the top, then a 
>>horizontal line and other options such as "Gad  / Gadara  / 
>>Gideon... etc). This will esp help those who don't know the Bible 
>>books well, or who type "Jud" for Judges and end up in Jude.
>> >>> All very feasible
>>* Could we add some kind of chapter selection? Perhaps, when 
>>"Genesis 1..." is selected the dropdown could change to "Genesis 1 
>>/ Genesis 2 / Genesis 3 / Genesis 3 / ..."
>> >>> I think you mean "Genesis "  would come up with Genesis 1, 
>> Genesis 2, etc. Genesis 1 would come up with Genesis 11, Genesis 
>> 12, etc. I think also the Bible function on the left (maybe we 
>> only need one) could server that purpose, as a drill down. So your 
>> side popup would appear, you'd click Genesis, then get a list of 
>> all the chapters, then click a chapter...
>>* AND / OR we could put a Bible icon by the side of the Search box 
>>with a drill-down Bible book & chapter selection.
>>* When we implement Browser functions (like extending the page 
>>downward, or using child windows, we have to remember that not all 
>>Browsers are equal, esp on a phone or an iPad. We can't rely on 
>>extra space and extra windows being available.
>>Agreed, a comment from my flat mate however was that if we're 
>>squeezing the Bible into these two panes, and they are not linked 
>>(ie. different versions/passage/content) we may need to expand them 
>>downwards like a proper webpage for fear of not displaying enough 
>>of the passage. I'd rather avoid inline scroll bars...
>>* I like the big popout area from side bar, but perhaps it should 
>>cover only the left-hand text pane (and it could cover more of it) 
>>- so that the user can arrange to have the passage they are looking 
>>up to still be visible on the right-hand pane. Eg someone may be 
>>looking up "Jehoshaphat" and they'd want to see the name while 
>>searching for it.
>>  - this would also help with smaller devices, on which we can 
>> display either one text pane or the other, but not a wide area spanning both.
>> >>> Good idea
>>* That makes me think it would be nice to be able to swap the right 
>>& left text panes. Can the "bridge" icon serve double purpose somehow?
>> >>> Maybe dragging and dropping the pane onto the other side?
>>* What about putting the left-hand buttons on the right-hand side? 
>>I'm thinking about how this will be approached. Most users start at 
>>the left and the big buttons make them think that this is what they 
>>want to choose first, whereas we want the Bible text to be the 
>>center and the other things to be spokes or offshoots. So if the 
>>big buttons are on the right, their eyes will be drawn first to the 
>>main searchbox, which is where we want them to start. And if there 
>>is a Bible icon to the left of the search, this should lead them to 
>>drill down to a Bible chapter. Also, if the popout is on the right, 
>>it is less likely to cover the very text they have selected.
>> >>> Possibly. I'll try that and post a screenshot.
>>* If the popout is covering the complete right-hand text pane, we 
>>should make sure that IF the two panes are linked, we temporarily 
>>unlink them so that a user can scroll up and down through the 
>>complete text in just the left-hand pane which they can still see, 
>>while the popout obscures the right-hand side.
>>* The Bible icon in the big buttons should perhaps lead to 
>>commentaries rather than Bible books - ie keep the theme that these 
>>buttons are all adjuncts to the text.
>> >>> Yup, I was thinking that as well... Maybe a little Bible icon 
>> next to the search, which would just populate the auto-suggest 
>> search box at the top.
>>This is really taking shape!
>>David IB
>>At 21:57 25/04/2010, Chris Burrell wrote:
>>>Some mock ups from me are now on the Tyndale Programming blogs: 
>>>Comments are welcome, whether good or bad!!! I think whatever 
>>>happens, the icons would need to be harmonized (colour an style) 
>>>and thought through a bit. And obviously the colour scheme would 
>>>need to be chosen carefully  (do we also want to make colour blind 
>>>people have easy access, etc.?)
>>>The first two screenshots go together:
>>>where the second one is when the user has clicked a button on the 
>>>left hand side.
>>>And then there's the explanations of some of the layouts if need be:
>>>Finally, there's a couple of extra screenshots:
>>>The first showing an alternative of the bit in the middle of the book:
>>>where it would list the content we have about a particular passage
>>>and then one that looks particularly green (the green from one of 
>>>the logos that was on the blogs a few weeks ago: 
>>>A few other remarks:
>>>1st: we're going to run this thing in a browser (whether online or 
>>>offline), so we can make use of the browser buttons (back and 
>>>forth), most naturally to capture content change, similar to the 
>>>bookmarks, going back and forth through the passages we've 
>>>visited. (that is stateless, i.e. if we came back tomorrow that 
>>>history would be forgotten about).
>>>2ndly, it's a browser, so we can expand the page downwards (by 
>>>inserting content at the top), or at the bottom. We can also use 
>>>internal links to go between one screen and another.
>>>3rdly: we could include some sort of menus at the top to make it 
>>>feel more desktop-like. Not sure what I think about that.
>>>4th: we do need a place of general configuration and user 
>>>preferences (things like proxy settings, installing more sword 
>>>modules/bibles, etc.). Generally most of that can be done on a 
>>>separate page, but we need a way of accessing it, even if it's 
>>>just one button at the top right, or something like that.
>>>I think that's it from me for now...
>>>Please do let me know what you all think!?
>>>At 22:38 22/04/2010, Chris Burrell wrote:
>>>>Just thought I'd share a few sites that have cropped up recently 
>>>>from various people in the listings and outside. If we could pull 
>>>>ideas off those interfaces, I think we could end up with 
>>>>something really good.
>>>>2- http://code.google.com/p/xulsword/
>>>>3- <http://www.bibleglo.com/>http://www.bibleglo.com/
>>>I like lots of things in XulSword.
>>>What I liked about OffLineBible:
>>>* Bookmarks - click on it, and it displays the ref it is marking.
>>>* different formats (no Strongs; inline Strongs, interlinear 
>>>Strongs, columns
>>>* the line along the top where you can pick a chapter (a bit 
>>>fiddly to use, but an interesting idea)
>>>* all the bling. OK, it isn't necessary, but it looks cool - well, 
>>>* the add campaign (now that advertising can be free, who says it 
>>>doesn't pay?)
>>>OK, Here are some positive ideas:
>>>I like the idea of two panes of text, as in the prototype, and in XulSword,
>>>with a wide tab area for navigation on the left as in XulSword,
>>>* the XulSword tabs are in two columns with a narrow left-hand 
>>>column of OT/NT,
>>>    and a wider right-hand column which lists of books for OT or  NT
>>>    but I think we can develop that further:
>>>     Instead of having just OT and NT in the narrow left-most tab, 
>>> we can have other things,
>>>     which bring up more things in the wider right-hand tab:
>>>   - OldT - listing OT books
>>>   - NewT - listing NT books
>>>   - Geog - listing placenames
>>>   - Hist - listing periods
>>>   - Lit - listing significant extra-biblical books
>>>   - Lang - listing languages
>>>   - Who - listing people
>>>   - Find - a search box listing results
>>>With some of these, we will have to display a cut-down list, perhaps with
>>>[+] at the side to open up the item into more detail, eg for people:
>>>[+] Aaron
>>>[+] Baalam
>>>[+] Caanan
>>>- giving just 26 entries displayed.
>>>For Languages I'd suggest an interface like 2LetterLookup.com
>>>The equal sized panes of text could be like in XulSword, ie:
>>>* each pane can show a different chapter of the Bible
>>>   or the same chap in a different version, or they can be
>>>   linked to show more of the chapter, flowing from one to the other.
>>>* a raisable bridge icon  (like London Tower Bridge?) can join or 
>>>separate them
>>>* both panes have an identical set of tabs across the top
>>>* these tabs need to be in two layers, classifying them into
>>>   - English (ie PD versions)
>>>   - European, (ie other language groups)
>>>   - African
>>>   - Eastern  (etc  as needed)
>>>   - Online  (ie IFrames to NIV and other commercial version websites)
>>>   - Ancient (ie Greek, Hebrew, ancient versions)
>>>* at the bottom of each pane, there's a box which minimises when not in use
>>>* below this box is another set of tabs determining what these boxes show
>>>    (and when the box is minimised, they remain as a set of buttons)
>>>* These tabs include:
>>>    - footnotes (ie all the footnotes of verses in that chapter)
>>>    - cross-refs (ie all the crossrefs of verses in that chapter)
>>>    - personal notes (for that chap)
>>>    - names  (ie all the people and places named, with links to 
>>> dictionaries)
>>>    - timeline (ie a minimised view of the time represented by 
>>> that chapter)
>>>    - vocab (ie all Greek, Hebrew and English words which occur in 
>>> the chapter)
>>>* between the two text panes put a column of bookmarks,
>>>   with an arrow in both directions, so you can open in either pane
>>>* at the top are "manual" bookmarks and at the bottom are 
>>>"automatic" bookmarks
>>>  - add a manual bookmark by clicking on an arrow at the top 
>>> middle of each text
>>>  - an automatic bookmark is added everyone a pane moves away from 
>>> a chapter
>>>    by any means other than scrolling
>>>* the two sets of bookmarks accumulate vertically in order of setting them
>>>   and when they run out of room, there is a scroll function to 
>>> see older ones
>>>* a "back" button at the top of each text pane keeps a history of 
>>>what was displayed on that pane
>>>* when you hover over a tagged word, definitions etc appear as a hover
>>>* this hover does NOT appear next to the cursor, but always in the 
>>>Tab area on the left,
>>>    because this area is not being used once a person has gone 
>>> where they want to go,
>>>    whereas an overlay by the cursor obscures the exact text being studied
>>>*  hover works within the text panes, and also in the boxes
>>>    - hovering over a cross-ref shows the verse,
>>>    - hovering over a Greek word in the text pane or a box shows a 
>>> lexicon entry
>>>    - hovering over a place name in text or pane or a box shows 
>>> dictionary entry
>>>    etc
>>>* when you click on a ref (rather than hovering over it), the 
>>>left-hand text pane
>>>   goes to that chapter and highlights the verse clicked on
>>>* when you click on a word or place or date (rather than hovering over it),
>>>   the right-hand text pane shows a full lexicon or map or timeline.
>>>* A Search box is permanently visible at top left, above the Tabs
>>>   and results appear in the wider right-hand Tabs area
>>>   - this searches for English, Greek, Hebrew, numbers (for 
>>> Strongs) and Refs
>>>     working out for itself what it is searching for.
>>>We have LOTS of data to display, but we want to try and 
>>>accommodate small screens - big problem!
>>>Let's assume that phone screens will get bigger.
>>>My Toshiba G910 has 800x600 pixels in eye-watering 2.5"x1.7" size, 
>>>which is great for those under 40,
>>>but as soon as your lenses harden, you need +3 glasses to see the details.
>>>I think phones will go in the way of high-density screens, though 
>>>laptops may not follow.
>>>But I don't think we should assume that we will have this much space.
>>>Although  we can display a lot, people can't see so much detail.
>>>On small screens, we can treat the three areas (tabs on the left, 
>>>and two text panes)
>>>as separate screens which you drag into view as on an iPhone.
>>>With small screens, the hover area will have to be near the 
>>>cursor, as in most systems.
>>>Can someone with artistic skills make a visual of all this?
>>>David IB
>>>sword-devel mailing list: 
>>><mailto:sword-devel at crosswire.org>sword-devel at crosswire.org
>>>Instructions to unsubscribe/change your settings at above page
>sword-devel mailing list: sword-devel at crosswire.org
>Instructions to unsubscribe/change your settings at above page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20100428/0a33d13d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Searchbox.jpg
Type: image/jpeg
Size: 18563 bytes
Desc: not available
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20100428/0a33d13d/attachment-0001.jpg>

More information about the sword-devel mailing list