Web front end

DezmondFinney · 08-09-2011, 04:34 AM

I am still hacking away at the front end for the web server. There is a new video of my progress up at vimeo.

So far this is just a drop in replacement. Drop in the new content_server folder and restart the server. I do not think it will remain that way for long. I would like to clean up some of the code generated by cherrypy. (I am getting more familiar with it little by little - it's cool but not my cup o' tea so it's taking a while)

Specifically, the mobile support bites right now. (Though the "old" mobile version is untouched) There are alot of sections that are not styled completely.

I have started refactoring the JS as well so at this point some things like the sort feature kinda break.

Other than that things are rolling.

Question: Is there anyone who would appreciate having this available in a repo? If so I can make my work available at github (or somewhere else). Just let me know.

user_none · 08-09-2011, 07:28 AM

Quote:

Originally Posted by DezmondFinney

Question: Is there anyone who would appreciate having this available in a repo? If so I can make my work available at github (or somewhere else). Just let me know.

I would recommend Launchpad as that is what calibre uses for development. Your branch would show up with the others so people looking to contribute can easily see what your doing.

Caleb666 · 08-09-2011, 07:54 AM

I noticed that some extra controls (including the book rating) appear when the mouse hovers the book... that probably won't be wise when you're dealing with touch-devices. I don't know about others, but I know that I only access the content server from my iPad... I don't need to access it from a PC.
So you should probably optimize the UX for touch-based devices (tablets, smartphones), so there will be a lot less clicking/tapping involved to see some basic book information.

Now I wonder, should the book's rating be displayed while you browse (as it is now), or only in the book details?

Also, do you have any plans to add proper support for hierarchical categories? Right now the web front end will display hierarchical categories by giving a flat listing of the its elements. I haven't really put much thought into what the best way to do that though...

kovidgoyal · 08-09-2011, 09:45 AM

Some users are going to want the ability to browse using a booklist with more data up front, instead of just covers and title/author.

I also recommend using launchpad. Instructions for using bzr+launchpad are in the setting up a development environment section of the user manual

DezmondFinney · 08-09-2011, 03:44 PM

The user interface that is in the video is for the desktop. Using media queries the interface will adjust for mobile (including tablets). My next video will show what it will look like hopefully. Unfortunately, I do no have a tablet to do testing but I will do my best.

Originally I was going to have a more details be visible to the mobile user up front but from what you say, kovidgoyal it may be best to have a toggle switch on the desktop version as well. It's a matter of what's most important to the user. Viewing more books or more details for each book. The most important things for me are (in order) Title, Author, Download, and Rating all of which are easily visible. What other information would you consider imperative?

I too would like to have better hierarchical support. There are 2 ways I can do it: via dom manipulation or on the server itself. The later is preferable for mobile devices to minimize the amount of client side work but if I do that it will be a feature that will have to wait until I have a better understanding of cherrypy. I really like the fact that so far this is a drop in replacement for anyone including those with binary installs not just those who want to compile from source.

I will try to have things cleaned up and into a repo as soon as possible.

kovidgoyal · 08-09-2011, 04:05 PM

A couple of lines from comments is also useful. As well as tags (see the current content server interface). But, more importantly, I meant having that information be visible without the need to hover over entries. Scanning over a list is a lot faster than having to hover over each item individually. This is particularly important in the scenario where you are displaying a small set of books, say the result of a search or if the user goes via a tag/series/author/etc.

Not to mention that you cannot hover on touch based interfaces.

DezmondFinney · 08-10-2011, 02:57 AM

Here is a slightly tweeked version based on some of the feed back.

The question that I have is should I continue working on the "drop in" replacement or should I work on a version that requires the source? Modifying the source would be easier in many ways but would be inaccesable until (if) it where merged into the trunk.

kovidgoyal · 08-10-2011, 09:51 AM

Much better

Maybe have the individual book blocks have an auto vertical scrollbar? Also probably you could move other formats to the right of the cover, as there is wasted space there.

I say if you need to modify the source, modify it. If you want your code merged into trunk, it needs to be as maintainable as possible, which means doing things the "right" way.

There are many people that run calibre from source, so you should still get feedback.

08-09-2011, 04:34 AM	#1
DezmondFinney Member Posts: 18 Karma: 10 Join Date: Aug 2011 Location: Atlanta, Ga Device: kindle	Web front end I am still hacking away at the front end for the web server. There is a new video of my progress up at vimeo. So far this is just a drop in replacement. Drop in the new content_server folder and restart the server. I do not think it will remain that way for long. I would like to clean up some of the code generated by cherrypy. (I am getting more familiar with it little by little - it's cool but not my cup o' tea so it's taking a while) Specifically, the mobile support bites right now. (Though the "old" mobile version is untouched) There are alot of sections that are not styled completely. I have started refactoring the JS as well so at this point some things like the sort feature kinda break. Other than that things are rolling. Question: Is there anyone who would appreciate having this available in a repo? If so I can make my work available at github (or somewhere else). Just let me know.

08-09-2011, 04:05 PM	#6
kovidgoyal creator of calibre Posts: 43,826 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	A couple of lines from comments is also useful. As well as tags (see the current content server interface). But, more importantly, I meant having that information be visible without the need to hover over entries. Scanning over a list is a lot faster than having to hover over each item individually. This is particularly important in the scenario where you are displaying a small set of books, say the result of a search or if the user goes via a tag/series/author/etc. Not to mention that you cannot hover on touch based interfaces. Last edited by kovidgoyal; 08-09-2011 at 04:13 PM.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
soPDF GUI Front-End	Nathan Campos	PDF	37	11-04-2011 07:45 PM
Hacking the front-end	DezmondFinney	Development	18	08-05-2011 03:22 AM
GuteBook - the Project Gutenberg eBook Maker/Front-end	nrapallo	Workshop	67	03-27-2011 04:46 PM
Web Standards for E-books by Joe Clark (web article)	guyanonymous	General Discussions	2	03-18-2010 10:36 PM
Mobile Web surfing on the rise says Face of the Web	Alexander Turcic	Lounge	2	04-20-2006 01:17 PM

08-09-2011, 07:54 AM	#3
Caleb666 Zealot Posts: 100 Karma: 400000 Join Date: Jul 2010 Device: iPad 2 64GB	I noticed that some extra controls (including the book rating) appear when the mouse hovers the book... that probably won't be wise when you're dealing with touch-devices. I don't know about others, but I know that I only access the content server from my iPad... I don't need to access it from a PC. So you should probably optimize the UX for touch-based devices (tablets, smartphones), so there will be a lot less clicking/tapping involved to see some basic book information. Now I wonder, should the book's rating be displayed while you browse (as it is now), or only in the book details? Also, do you have any plans to add proper support for hierarchical categories? Right now the web front end will display hierarchical categories by giving a flat listing of the its elements. I haven't really put much thought into what the best way to do that though...

08-09-2011, 09:45 AM	#4
kovidgoyal creator of calibre Posts: 43,826 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Some users are going to want the ability to browse using a booklist with more data up front, instead of just covers and title/author. I also recommend using launchpad. Instructions for using bzr+launchpad are in the setting up a development environment section of the user manual

08-09-2011, 03:44 PM	#5
DezmondFinney Member Posts: 18 Karma: 10 Join Date: Aug 2011 Location: Atlanta, Ga Device: kindle	The user interface that is in the video is for the desktop. Using media queries the interface will adjust for mobile (including tablets). My next video will show what it will look like hopefully. Unfortunately, I do no have a tablet to do testing but I will do my best. Originally I was going to have a more details be visible to the mobile user up front but from what you say, kovidgoyal it may be best to have a toggle switch on the desktop version as well. It's a matter of what's most important to the user. Viewing more books or more details for each book. The most important things for me are (in order) Title, Author, Download, and Rating all of which are easily visible. What other information would you consider imperative? I too would like to have better hierarchical support. There are 2 ways I can do it: via dom manipulation or on the server itself. The later is preferable for mobile devices to minimize the amount of client side work but if I do that it will be a feature that will have to wait until I have a better understanding of cherrypy. I really like the fact that so far this is a drop in replacement for anyone including those with binary installs not just those who want to compile from source. I will try to have things cleaned up and into a repo as soon as possible.

08-10-2011, 02:57 AM	#7
DezmondFinney Member Posts: 18 Karma: 10 Join Date: Aug 2011 Location: Atlanta, Ga Device: kindle	Here is a slightly tweeked version based on some of the feed back. The question that I have is should I continue working on the "drop in" replacement or should I work on a version that requires the source? Modifying the source would be easier in many ways but would be inaccesable until (if) it where merged into the trunk.

08-10-2011, 09:51 AM	#8
kovidgoyal creator of calibre Posts: 43,826 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Much better Maybe have the individual book blocks have an auto vertical scrollbar? Also probably you could move other formats to the right of the cover, as there is wasted space there. I say if you need to modify the source, modify it. If you want your code merged into trunk, it needs to be as maintainable as possible, which means doing things the "right" way. There are many people that run calibre from source, so you should still get feedback.