Notices

I like the infinite scroll idea a lot. The whole "get to the end of a chapter and jump to the next" (similar to jumping pages in some PDF viewers) is unnatural and one of my dislikes about Rapier.

ARJWright, it looks like you've really thought about how to adapt to a small touchscreen. It would be great if core functions like "go to chapter & verse" and "read" and maybe even "word search" could be done just with finger input. Re: your buttons like "Commentary" and "Maps", I would vote for having this functionality accessible in some kind of pop-up to save precious screenspace for the text.

There is a tentative format for storing annotations, I just don't remember where I saw it off-hand. I might have written about it at MMM, and at the same time, I know that its benn a topic of discussion at Sword, YouVersion, and Bible+. Making the format shouldn't be a problem given the coding abckgrounds of all of us here. It would be fun to make a landmark app if this were the case.

Edit: Ding!
http://mobileministrymagazine.com/20...in-detail.html

In terms of navigation, bear with me, I dream a bit:

gesture up from middle of the screen to top to go to previous chapter; from same spot, gesture down to go to next chapter

gesture swipe left to page back, swipe right to page forward (there's no need to go verse by verse, this isn't a teleprompter)

gesture from top to bottom of the screen counterclock wise to open the go to screen; gesture top to bottom clockwise to go to settings menu

circle a word or series of them to highlight, this brings up context menu to copy/note/etc.

If you will, leave the text there, and allow the interaction thru gestures to allow people to dig into the text. This would not only lessen the barrier to entry, but will push a standarization towards gestures that Maemo should be pushing given its audience.

Plus, its fun

A simple 'page turn' which moves the whole screen on is more usable to me than the ''next verse' move. On that I find reading aloud very challenging: my eye doesn't actually know where on the page to start. If you start at the top of the page after every 'turn', you know where you are. You know, like those funny paper things... books.

That's why I like the infinite scroll idea. You just drag &/or flick up or down to scroll up or down, right? You don't need to distinguish between "next chapter" and "next verse" commands.

How about implementing a UI where portrait mode is a plain reader - page by page - and landscape brings up the search/annotate controls?

Of course, that pretty much nixes the browser-based idea...

Ironically enough, MMM got an email (in the past few days) asking about this widget idea that was posted some time ago:

http://mobileministrymagazine.com/20...le-widget.html

There are a lot of ways to tackle the question of how to put a Bible on a Mameo 5 device. Its up to developers (and publishers) to figure out the ways that would present the least amount of friction to users.

Hogwash, any progress on the Sword-based port?

In the process of fiddling around with it, I seem to have FUBARed my Maemo dev env so that the simulator crashes at the slightest provocation. I think i'll start over using a virtualized vanilla debian install so that i can easily restore it the next time i do that. It's so hard to extrapolate from a mouse-interfaced UI on my desktop to a handheld that i may not actually try anything until i have an N900 in my hot little hand so that i can test things as i go.

Just spamming up the thread to say 'Thank You' again to the people working on this one!

I just found this thread; and noticed you were doing the same stuff I was doing Hogwash....

Ok, I had no issues at all compiling CLucene in the Scratchbox however, running the Tests it fails out with a double free glib error. That concerns me... Did you by any chance build the tests in scratchbox and run them. I'm curious if you saw this issue?


libcurl I believe is already present in scratchbox. Sword didn't look like it would be a problem.

BibleTime, I was looking at that one too since it is QT4 based. Boost, what needed boost? I also was looking a GnomeSword (Can't remember their new name) since its front end is abstracted out so basically we just would need to stick a new QT4 front end on it and we would inherit all the work that they have done. ;-D

Nathan