Active Topics
-
The N900 is now 15 years old! (9)
to Nokia N900 by Arno_11 - 1 hr, 11 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 5 days, 13 hrs ago - more...
 |
|
2009-10-09
, 18:51
|
|
Posts: 861 |
Thanked: 734 times |
Joined on Jan 2008
@ Nomadic
|
#72
|
Originally Posted by Flandry
If you go the browser route, there are two approaches that I've seen that work best here (and elsewhere):
The browser route is something i plan to explore, but i'm waiting to see if add-ons for the N900 Maemo Browser become available. I don't really need the majority of what Sword provides, and not having to deal with their modules and code make the whole project much less heavy.
My Zim notes:
DOM-modification
• MicroB for OS2008 supported Greasemonkey addon
• http://shiftspace.org scripts do highlighting and annotations as well as providing a centralized server for storage and a sharing mechanism
Some custom hacked-down version of the shitfspace project combined with a simple downloader/packager for the texts could provide a very nice reading experience right within the browser.
- design an addon in the wise of Firefox-like extensions. Depending on the changes that have occured within MicroB's engine for Maemo 5, you might/might not have all of the same features that you would if you built one for Firefox/Mobile Firefox (Fennec). That being said, this would enable you to pretty much graft functionality on top of some of the Bible websites out there, and then pretty much extend the browser (and maybe a widget on the homescreen) to better usages.
- develop a Greasemonkey like script that sites on top of some established library, which offers add-on like functionality, but is constrained a bit more to a specific site/resource. With this method you'd get more buy-in from the publisher of various sites, and its definitely a less of a legal hassle, But you are limited to a degree.
---
Regardless of what is used to make the application, there are a few things that I'd pretty much say to keep in mind (since this is essentially a clean sheet effort)
- reading is key, therefore devote the screen to this over controls
- searching is key, therefore devote the primary navigation and toolsets to this
Personally, something along the lines of a search box-based widget that calls into a custom browser window the content from either a local or web-based bible resource would work very well. The box would have to be versatile enough to read and understand one or more versus or subjects in there.
Add a plug-in like system to enable people to save searches as RSS feeds, or export verses to the buiilt-in notepad, and you have something that is simple to use and powerful as well. Or a plugin that saves searches and bookmarks in an XML file, so that from that same search box such tags could be called up again, and then you have something versatile and befitting the open nature of the platform.
Seriously, I wish I could code, because I've had this idea for an app for an insanely long time (heck, I assisted the developers of Palm Bible+ with that UI because I was so interested in just simple reading and annotating). Because I can't, I hope these suggestions work to help you folks who are coding out a bit.
|
|
2009-10-09
, 18:53
|
|
Posts: 111 |
Thanked: 80 times |
Joined on Oct 2009
|
#73
|
Originally Posted by Flandry
Yep, that's right.
Re: scroll Ok, so the problem is you want to have kinetic scrolling, but need to also dynamically load books as you come to them. Right?
Originally Posted by Flandry
I would be open to considering side-by-side comparison, but I would have them infinitely scroll together. I don't think the too ideas are in conflict with each other.
Re:Concept wireframes Nice. So you don't see side-by-side comparative display as part of ideal reader on a small display? Would you on a larger screen?
|
|
2009-10-09
, 18:56
|
|
Posts: 111 |
Thanked: 80 times |
Joined on Oct 2009
|
#74
|
Originally Posted by ARJWright
My hunch with the browser route is that it will be (much?) easier to get a clunky solution working, but impossible to get something *really* good. I'm shooting for simple and *really* good. :-)
If you go the browser route, there are two approaches that I've seen that work best here (and elsewhere):
|
|
2009-10-09
, 19:06
|
|
Posts: 861 |
Thanked: 734 times |
Joined on Jan 2008
@ Nomadic
|
#75
|
Originally Posted by Flandry
Crud, sorry, I missed this earlier, but its good as there is good time to explain my reasoning.
Re:Concept wireframes Nice. So you don't see side-by-side comparative display as part of ideal reader on a small display? Would you on a larger screen?
#1: you are on a mobile device with a limited amount of screen real estate towards the text-size/width's viewable ranges.
#2: side by side can be done better when taking a similar approach that Maemo has with the homescreen - allowing for panes (workspaces) verus breaking the HID with two windows as we are used to on larger displays ( see post about linear user interfaces at the TabletUI blog)
The user interface and expected user experience on a large screen should never be mapped to a smaller screen.
Developing an interface should take into account the user, the actions they wish to do, and the space in which they are doing it. For example, comparative versus studies can be done when sitting at a desk or when in a line at the bank. However, at your desk, you expect to have not just the screen space, but the additional input mechanisms of keyboard and mouse to aid you pulling content. With the smaller device and in line, your hands are occupied, and therefore the process of finding the verse and looking at it beside the one you wish to compare has to take a different road to the same end.
If I can get the time (and in front of Visio), I'll mock up something near what I am talking about.
 |
|
2009-10-09
, 19:12
|
|
Posts: 1,559 |
Thanked: 1,786 times |
Joined on Oct 2009
@ Boston
|
#76
|
That's probably true, but it depends a lot on what features are needed.
Because i'd be happy with a clean, attractive display of the text with a very simple interface to highlight portions and add annotations, the browser seems like it might be the shortest route to a very polished product. If i was trying to compare texts side-by-side and do a lot of dictionary lookup, i'd definitely not waste effort with a browser.
The thing is, i get hung up on the portability of the annotations. I don't want to lose them on my desktop or in a few years as tech changes, and that's the real challenge. A layer that sits on top of a standardized browser platform seems like it has a decent chance of being portable to desktop, and future tech...
Incidentally, that's why i asked ARJ about whether he thought the ideal interface for a maemo device used just a single display (rather than split screen): if the IT is too small to effectively use a split screen, anyway, it makes the browser approach more appealing.
Edit: the above was written before the last post. It sounds like you're confirming that the IT is just too small to justify a split screen UI?
Last edited by Flandry; 2009-10-09 at 19:17.
Because i'd be happy with a clean, attractive display of the text with a very simple interface to highlight portions and add annotations, the browser seems like it might be the shortest route to a very polished product. If i was trying to compare texts side-by-side and do a lot of dictionary lookup, i'd definitely not waste effort with a browser.
The thing is, i get hung up on the portability of the annotations. I don't want to lose them on my desktop or in a few years as tech changes, and that's the real challenge. A layer that sits on top of a standardized browser platform seems like it has a decent chance of being portable to desktop, and future tech...
Incidentally, that's why i asked ARJ about whether he thought the ideal interface for a maemo device used just a single display (rather than split screen): if the IT is too small to effectively use a split screen, anyway, it makes the browser approach more appealing.
Edit: the above was written before the last post. It sounds like you're confirming that the IT is just too small to justify a split screen UI?
Last edited by Flandry; 2009-10-09 at 19:17.
|
|
2009-10-09
, 19:34
|
|
Posts: 861 |
Thanked: 734 times |
Joined on Jan 2008
@ Nomadic
|
#77
|
Originally Posted by Flandry
Getting annotations/bookmarks/etc. trapped in an app is the wrong way to go with a Bible app IMO. I've ranted on that enough times, and still haven't been able to convince publishers/bible software makers that people want their data apart from the content they offer.
That's probably true, but it depends a lot on what features are needed.
Because i'd be happy with a clean, attractive display of the text with a very simple interface to highlight portions and add annotations, the browser seems like it might be the shortest route to a very polished product. If i was trying to compare texts side-by-side and do a lot of dictionary lookup, i'd definitely not waste effort with a browser.
The thing is, i get hung up on the portability of the annotations. I don't want to lose them on my desktop or in a few years as tech changes, and that's the real challenge. A layer that sits on top of a standardized browser platform seems like it has a decent chance of being portable to desktop, and future tech...
Incidentally, that's why i asked ARJ about whether he thought the ideal interface for a maemo device used just a single display (rather than split screen): if the IT is too small to effectively use a split screen, anyway, it makes the browser approach more appealing.
Edit: the above was written before the last post. It sounds like you're confirming that the IT is just too small to justify a split screen UI?
Its not so much that its too small - you could shoehorn it in there as Rapier as done. The thing is, is that UI the right one for what we'd propose is a reason for having a bible reader. I don't think that it is.
Something more along the lines of a tap-and-hold on a term/verse with a context menu that comes up that says "Define | Compare | Bookmark | Annotate" and then moves to a new screen that has either a definition from a comparative source, cross references (from an index or comparative source), an input bookmark interface, or a simple notes interface (possibly with a tag field so it can be searched on later).
That's at least how my brain seems to work, along with many others who use digital bible devices/editions.
|
|
2009-10-09
, 20:21
|
|
Posts: 1,559 |
Thanked: 1,786 times |
Joined on Oct 2009
@ Boston
|
#78
|
Originally Posted by ARJWright
I'm a bit confused by this comment because it echoes my own sentiment, yet it seems like you're saying my approach is inherently bad because it somehow ignores this issue.
Getting annotations/bookmarks/etc. trapped in an app is the wrong way to go with a Bible app IMO. I've ranted on that enough times, and still haven't been able to convince publishers/bible software makers that people want their data apart from the content they offer.
The real problem here is compatibility, of course. There's no general specification that i'm aware of for ebook annotations (is there for bible readers?), so overlaying the user-generated content on a generic interface (e.g.browser canvas) based on some peeping of the DOM seems actually fairly robust, in that it might be portable and outlast any particular implementation.
n.b. I have very little experience with UI programming or ECMA script, so I don't know how practical and scalable such an approach would be. After the discussion here, it just seems like the best way to do it.
Something more along the lines of a tap-and-hold on a term/verse with a context menu that comes up that says "Define | Compare | Bookmark | Annotate" and then moves to a new screen that has either a definition from a comparative source, cross references (from an index or comparative source), an input bookmark interface, or a simple notes interface (possibly with a tag field so it can be searched on later).
That's at least how my brain seems to work, along with many others who use digital bible devices/editions.
|
|
2009-10-09
, 20:24
|
|
Posts: 369 |
Thanked: 191 times |
Joined on Sep 2009
@ Virginia
|
#79
|
If annotations/bookmarks/etc can be stored in a well defined XML grammar, external to the app, then other products would have a heckuva easier time translating that into something they could use, if not use it directly.
|
|
2009-10-09
, 20:29
|
|
Posts: 861 |
Thanked: 734 times |
Joined on Jan 2008
@ Nomadic
|
#80
|
I'm a bit confused by this comment because it echoes my own sentiment, yet it seems like you're saying my approach is inherently bad because it somehow ignores this issue.
 |
| Tags |
| bible, maemo 5, rapier, reference browser, religious apps, scripture reader, sword |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 18:53.
My Zim notes:
DOM-modification
• MicroB for OS2008 supported Greasemonkey addon
• http://shiftspace.org scripts do highlighting and annotations as well as providing a centralized server for storage and a sharing mechanism
Some custom hacked-down version of the shitfspace project combined with a simple downloader/packager for the texts could provide a very nice reading experience right within the browser.