Ideas about book landing page & metadata presentation
Hello, gutvol-d. This list has been very quiet, and if you discover you no longer want to receive messages you can visit https://lists.pglaf.org to unsubscribe (unsub instructions are also part of the email header). I am wondering whether you have ideas about how to present a more effective landing page for our eBooks. The situation is that I am trying to make the collection more self-contained, and remove some of the back-end processing we use to present information about the books. Take a look at any current eBook landing page, such as https://www.gutenberg.org/ebooks/56843 This is plain HTML (with Javascript and CSS), but it does not come from a static file. Basically, what I'd like to do is recreate a similar page, but as a static file, without relying on a back-end database, and without using Javascript. I.e., plain HTML with CSS. The actual files are in a location like this: https://www.gutenberg.org/files/56843/ My intention is to make a directory (folder) that has those files, plus the generated files (i.e., you can see them here: http://aleph.gutenberg.org/cache/epub/56843/) plus an index.htm or similar that presents the landing page. Oh, and we'll give all the files nice human-friendly usernames. There is already some code for that in epubmaker. MY INQUIRY is for ideas about the index.htm or similar that would be similar to the current landing page, but be (a) static, and (b) use no Javascript or other active content, and (c) allow variations on CSS, to have different "skins" for different viewers. General ideas: - HTML5 - works well with mobile and desktop - works well with text browsers and screen readers - might need to have two pages: one for bibrec info ("about.htm" perhaps?) and the other to access - get CSS style information from e.g., /gutensite/ , so that it is easy for people to apply their own styles. For example, mirrors might not want the dropbox/cloud links) I'm very interested in any mockups that you can think of. The idea will be to generate these static pages when new eBooks are added/updated. That way, when someone visits a page like https://www.gutenberg.org/ebooks/56843 , they will be seeing the static content under ebooks/56843. Currently, there is no such static content: it is all generated by a set of back-end Web-database applications. Thanks, Greg
Hi Greg, looks like a nice idea. These pages only change when the content changes, so only generating them at that time should be good enough. I few questions or remarks to clarify the requirements. 1. I currently see a few links to images from third party sites. (google, twitter, flattr). They give away browsing behavior to those third parties. I think we should avoid that. 2. There is a common set of icons. I think we should have some kind of (relative) master location for these, so we don't have to replicate them with every book. They should be part of the theme. 3. There is a QR code and scaled cover image, currently generated and placed in a cache, can we expect them to be there, or should we store them closer to the ebook. 4. Similar for the derived formats, we see they get a session id, and perhaps are generated on the fly. Can we assume such functionality to be available? Using different CSS stylesheets with the same page without either using Javascript or server side code is possible, but afaik, not widely supported, let alone known to end-users. Jeroen. Quoting Greg Newby <gbnewby@pglaf.org>:
Hello, gutvol-d. This list has been very quiet, and if you discover you no longer want to receive messages you can visit https://lists.pglaf.org to unsubscribe (unsub instructions are also part of the email header).
I am wondering whether you have ideas about how to present a more effective landing page for our eBooks.
The situation is that I am trying to make the collection more self-contained, and remove some of the back-end processing we use to present information about the books.
Take a look at any current eBook landing page, such as https://www.gutenberg.org/ebooks/56843
This is plain HTML (with Javascript and CSS), but it does not come from a static file. Basically, what I'd like to do is recreate a similar page, but as a static file, without relying on a back-end database, and without using Javascript. I.e., plain HTML with CSS.
The actual files are in a location like this: https://www.gutenberg.org/files/56843/
My intention is to make a directory (folder) that has those files, plus the generated files (i.e., you can see them here: http://aleph.gutenberg.org/cache/epub/56843/) plus an index.htm or similar that presents the landing page.
Oh, and we'll give all the files nice human-friendly usernames. There is already some code for that in epubmaker.
MY INQUIRY is for ideas about the index.htm or similar that would be similar to the current landing page, but be (a) static, and (b) use no Javascript or other active content, and (c) allow variations on CSS, to have different "skins" for different viewers. General ideas:
- HTML5 - works well with mobile and desktop - works well with text browsers and screen readers - might need to have two pages: one for bibrec info ("about.htm" perhaps?) and the other to access - get CSS style information from e.g., /gutensite/ , so that it is easy for people to apply their own styles. For example, mirrors might not want the dropbox/cloud links)
I'm very interested in any mockups that you can think of. The idea will be to generate these static pages when new eBooks are added/updated.
That way, when someone visits a page like https://www.gutenberg.org/ebooks/56843 , they will be seeing the static content under ebooks/56843.
Currently, there is no such static content: it is all generated by a set of back-end Web-database applications.
Thanks, Greg
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
On Mon, Mar 26, 2018 at 02:19:40PM +0000, jeroen@bohol.ph wrote:
Hi Greg,
looks like a nice idea. These pages only change when the content changes, so only generating them at that time should be good enough.
Yes, exactly. When files are updated, a new index.htm (or whatever) will be built. That is already the logic behind the site, but instead of a static file, we get things like a new coverpage thumbnail. More:
I few questions or remarks to clarify the requirements.
1. I currently see a few links to images from third party sites. (google, twitter, flattr). They give away browsing behavior to those third parties. I think we should avoid that.
Correct and agreed. We should not rely on external code or data in the index pages.
2. There is a common set of icons. I think we should have some kind of (relative) master location for these, so we don't have to replicate them with every book. They should be part of the theme.
Yes. Actually, we have one already (ftp/images or /images). We can rename as desired. I was thinking of /gutensite/ for css etc., so /gutensite/images could be a place for them.
3. There is a QR code and scaled cover image, currently generated and placed in a cache, can we expect them to be there, or should we store them closer to the ebook.
Yes, this will all be in the same directory as the other eBook files.
4. Similar for the derived formats, we see they get a session id, and perhaps are generated on the fly. Can we assume such functionality to be available?
Maybe? The session ID is generated by PHP. If we have static HTML+CSS, there will be no PHP or any programmable actions in the set of eBook files. However, we use Apache and it's easy enough to put a little PHP (or other languages/methods) via a top-level .htaccess, or even a .htaccess within the directory.
Using different CSS stylesheets with the same page without either using Javascript or server side code is possible, but afaik, not widely supported, let alone known to end-users.
Understood, and it probably wouldn't be used that way. Let's assume everyone visiting https://www.gutenberg.org/whatever would get the same view. Although I would not rule out using a .htaccess to run server-side code, as above, to select different skins or other characteristics. That could be done via cookies and a few lines of PHP or other simple logic. But this could be a feature ro the future. However, if someone wanted to make a private copy, they could use their own CSS and just put it in the right place, with the right filename. And, there might be reasons to have a separate master CSS for mirrors, versus the main site (for example, if mirrors cannot use the Google or Dropbox links, due to not having the needed back-end glue). - Greg
Quoting Greg Newby <gbnewby@pglaf.org>:
Hello, gutvol-d. This list has been very quiet, and if you discover you no longer want to receive messages you can visit https://lists.pglaf.org to unsubscribe (unsub instructions are also part of the email header).
I am wondering whether you have ideas about how to present a more effective landing page for our eBooks.
The situation is that I am trying to make the collection more self-contained, and remove some of the back-end processing we use to present information about the books.
Take a look at any current eBook landing page, such as https://www.gutenberg.org/ebooks/56843
This is plain HTML (with Javascript and CSS), but it does not come from a static file. Basically, what I'd like to do is recreate a similar page, but as a static file, without relying on a back-end database, and without using Javascript. I.e., plain HTML with CSS.
The actual files are in a location like this: https://www.gutenberg.org/files/56843/
My intention is to make a directory (folder) that has those files, plus the generated files (i.e., you can see them here: http://aleph.gutenberg.org/cache/epub/56843/) plus an index.htm or similar that presents the landing page.
Oh, and we'll give all the files nice human-friendly usernames. There is already some code for that in epubmaker.
MY INQUIRY is for ideas about the index.htm or similar that would be similar to the current landing page, but be (a) static, and (b) use no Javascript or other active content, and (c) allow variations on CSS, to have different "skins" for different viewers. General ideas:
- HTML5 - works well with mobile and desktop - works well with text browsers and screen readers - might need to have two pages: one for bibrec info ("about.htm" perhaps?) and the other to access - get CSS style information from e.g., /gutensite/ , so that it is easy for people to apply their own styles. For example, mirrors might not want the dropbox/cloud links)
I'm very interested in any mockups that you can think of. The idea will be to generate these static pages when new eBooks are added/updated.
That way, when someone visits a page like https://www.gutenberg.org/ebooks/56843 , they will be seeing the static content under ebooks/56843.
Currently, there is no such static content: it is all generated by a set of back-end Web-database applications.
Thanks, Greg
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
Hi Greg We have done something similar to be able to pack the whole collection in a ZIM file. Here is a demo web site: http://library.kiwix.org/gutenberg_mul_all_2014-11/ Source code is here: https://github.com/openzim/gutenberg Regards Emmanuel On 26.03.2018 15:13, Greg Newby wrote:
Hello, gutvol-d. This list has been very quiet, and if you discover you no longer want to receive messages you can visit https://lists.pglaf.org to unsubscribe (unsub instructions are also part of the email header).
I am wondering whether you have ideas about how to present a more effective landing page for our eBooks.
The situation is that I am trying to make the collection more self-contained, and remove some of the back-end processing we use to present information about the books.
Take a look at any current eBook landing page, such as https://www.gutenberg.org/ebooks/56843
This is plain HTML (with Javascript and CSS), but it does not come from a static file. Basically, what I'd like to do is recreate a similar page, but as a static file, without relying on a back-end database, and without using Javascript. I.e., plain HTML with CSS.
The actual files are in a location like this: https://www.gutenberg.org/files/56843/
My intention is to make a directory (folder) that has those files, plus the generated files (i.e., you can see them here: http://aleph.gutenberg.org/cache/epub/56843/) plus an index.htm or similar that presents the landing page.
Oh, and we'll give all the files nice human-friendly usernames. There is already some code for that in epubmaker.
MY INQUIRY is for ideas about the index.htm or similar that would be similar to the current landing page, but be (a) static, and (b) use no Javascript or other active content, and (c) allow variations on CSS, to have different "skins" for different viewers. General ideas:
- HTML5 - works well with mobile and desktop - works well with text browsers and screen readers - might need to have two pages: one for bibrec info ("about.htm" perhaps?) and the other to access - get CSS style information from e.g., /gutensite/ , so that it is easy for people to apply their own styles. For example, mirrors might not want the dropbox/cloud links)
I'm very interested in any mockups that you can think of. The idea will be to generate these static pages when new eBooks are added/updated.
That way, when someone visits a page like https://www.gutenberg.org/ebooks/56843 , they will be seeing the static content under ebooks/56843.
Currently, there is no such static content: it is all generated by a set of back-end Web-database applications.
Thanks, Greg
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d
-- Kiwix - Wikipedia Offline & more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication
Hi Greg. Thanks for the message. My understanding is that you want to change some of the behind-the-scenes procedures for how information about PG texts are presented to users, to use more static files, and less back-end processing. Based on previous experience, I would like to be aware of how this could affect those of us editing the catalog. Are you talking about still having a database, but generating static files from it, that are presented to users? Or are you talking about doing away with a central database altogether? Experience has shown that you do not want to automatically update catalog information when a book is updated or changed. There is a good chance you can overwrite improvements from catalog editors that way. --Andrew On Mon, 26 Mar 2018, Greg Newby wrote:
I am wondering whether you have ideas about how to present a more effective landing page for our eBooks.
The situation is that I am trying to make the collection more self-contained, and remove some of the back-end processing we use to present information about the books.
Take a look at any current eBook landing page, such as https://www.gutenberg.org/ebooks/56843
This is plain HTML (with Javascript and CSS), but it does not come from a static file. Basically, what I'd like to do is recreate a similar page, but as a static file, without relying on a back-end database, and without using Javascript. I.e., plain HTML with CSS.
The actual files are in a location like this: https://www.gutenberg.org/files/56843/
My intention is to make a directory (folder) that has those files, plus the generated files (i.e., you can see them here: http://aleph.gutenberg.org/cache/epub/56843/) plus an index.htm or similar that presents the landing page.
Oh, and we'll give all the files nice human-friendly usernames. There is already some code for that in epubmaker.
MY INQUIRY is for ideas about the index.htm or similar that would be similar to the current landing page, but be (a) static, and (b) use no Javascript or other active content, and (c) allow variations on CSS, to have different "skins" for different viewers. General ideas:
- HTML5 - works well with mobile and desktop - works well with text browsers and screen readers - might need to have two pages: one for bibrec info ("about.htm" perhaps?) and the other to access - get CSS style information from e.g., /gutensite/ , so that it is easy for people to apply their own styles. For example, mirrors might not want the dropbox/cloud links)
I'm very interested in any mockups that you can think of. The idea will be to generate these static pages when new eBooks are added/updated.
That way, when someone visits a page like https://www.gutenberg.org/ebooks/56843 , they will be seeing the static content under ebooks/56843.
Currently, there is no such static content: it is all generated by a set of back-end Web-database applications.
Thanks, Greg
Thanks for your note, Andrew. Comments below: On Tue, Apr 03, 2018 at 12:01:43PM -0700, Andrew Sly wrote:
Hi Greg. Thanks for the message.
My understanding is that you want to change some of the behind-the-scenes procedures for how information about PG texts are presented to users, to use more static files, and less back-end processing.
Based on previous experience, I would like to be aware of how this could affect those of us editing the catalog.
The intention is to regenerate the static HTML pages from the catalog, whenever something changes. This is the current practice for automatically generated content (epub, mobi, etc.).
Are you talking about still having a database, but generating static files from it, that are presented to users? Or are you talking about doing away with a central database altogether?
No, we'll keep the database. Maybe there will be some changes, but it will remain the canonical information source.
Experience has shown that you do not want to automatically update catalog information when a book is updated or changed. There is a good chance you can overwrite improvements from catalog editors that way.
Yes, this happens sometimes, still. For the most part, though, Marcello implemented some mechanisms to try to make sure that when other things change (i.e., updates to an eBook's files) it does not over-write anything in the database. That is definitely the same approach we will take. If eventually we end up with changes coming from elsewhere, we need to make sure they get into the database. For example, I have often wanted to crowdsource the addition of Wikipedia entries for authors and books. If that happens elsewhere (say, via a github-type process), I would want it to go back into the database, before being pushed out to the static pages. BTW, we have representation of the structured info from the database in every cache/epub directory (a little XML/RDF file). So, the database entries are already part of an eBook's files, but it's *from* the database, not input *to* the database. - Greg
On Mon, 26 Mar 2018, Greg Newby wrote:
I am wondering whether you have ideas about how to present a more effective landing page for our eBooks.
The situation is that I am trying to make the collection more self-contained, and remove some of the back-end processing we use to present information about the books.
Take a look at any current eBook landing page, such as https://www.gutenberg.org/ebooks/56843
This is plain HTML (with Javascript and CSS), but it does not come from a static file. Basically, what I'd like to do is recreate a similar page, but as a static file, without relying on a back-end database, and without using Javascript. I.e., plain HTML with CSS.
The actual files are in a location like this: https://www.gutenberg.org/files/56843/
My intention is to make a directory (folder) that has those files, plus the generated files (i.e., you can see them here: http://aleph.gutenberg.org/cache/epub/56843/) plus an index.htm or similar that presents the landing page.
Oh, and we'll give all the files nice human-friendly usernames. There is already some code for that in epubmaker.
MY INQUIRY is for ideas about the index.htm or similar that would be similar to the current landing page, but be (a) static, and (b) use no Javascript or other active content, and (c) allow variations on CSS, to have different "skins" for different viewers. General ideas:
- HTML5 - works well with mobile and desktop - works well with text browsers and screen readers - might need to have two pages: one for bibrec info ("about.htm" perhaps?) and the other to access - get CSS style information from e.g., /gutensite/ , so that it is easy for people to apply their own styles. For example, mirrors might not want the dropbox/cloud links)
I'm very interested in any mockups that you can think of. The idea will be to generate these static pages when new eBooks are added/updated.
That way, when someone visits a page like https://www.gutenberg.org/ebooks/56843 , they will be seeing the static content under ebooks/56843.
Currently, there is no such static content: it is all generated by a set of back-end Web-database applications.
Thanks, Greg
participants (4)
-
Andrew Sly -
Emmanuel Engelhart -
Greg Newby -
jeroen＠bohol.ph