ひまつぶし雑記帖

doncha.net制作・発行:KindleやiBooks、楽天kobo、BOOK☆WALKERで読む電子書籍

創作文芸見本誌会場HappyReading

2011/12/17 [17:40:42] (土) 天気

必要だろうと思った機能を最低限つけて、バグをひとつずつ潰して、まず最初の完成形となった。

とりあえずのメモ。

データベースは、mysqlではなくてsqlite。
どうして?lolipopのmysqlは重いので、ページ表示がもっさりしてしまう。レスポンスが早い、というのがwebの絶対正義。
sqliteは複数の同時アクセスに弱いという評判だけど?確かにその通りらしいけど、ウチぐらいのアクセスなら十分。むしろファイルひとつがそのままDBなので、バックアップなどのメンテがらくちん。そっちのメリットのほうが大きい。
mysqlとかpostgresqlのようなRDBが必要になったら、そのときそのままSQLなどは移せる。

データ構成は。
基本的に、一意に決まる本の情報以外の付属情報はすべてタグとして処理。著者やカテゴリなど。でも、イベント情報関係は別テーブルで管理(同人誌の場合、イベント参加情報は重要なので)
詳細ページを閲覧された回数や立ち読みされた回数はまた別管理で。モチベーションのため。

ページ表示に使うためのマスターテーブルは特になくて、idではなくて、ユーザー入力によるテキストのタイトル部分をキーにしている、というのが後々禍根を残しそうな予感。でもたぶん、そのおかげでおそらく内部SEO対策となる、はず。urlとページタイトルとコンテンツのh1の関連が強くなるし、そこで使われるキーワードがアンカーテキストとしてページ上部に出現する、いわゆるSEOとしては理想的な構造。

サイトの目的とか。
立ち読みをしてもらう。
面白かったら作者やサークル、カテゴリで芋づる式に次の立ち読みをしてもらう。
動線はそのために作る。それによって結果として内部SEO対策となる。

表示側。
一覧ページと詳細ページだけ。あとは、利用規約など。
サイトのトップページは必要ない?意図を持ってなにかをおすすめするとか企画するようなサイトではない。なので、単純にひらたく、なんらかの一覧ページをトップにすればいい。
ページの目的は立ち読みのテキストを読んでもらうことなので、一覧も詳細もワンクリックで立ち読みが開くように。
サークル名や著者名など本に付属するデータはすべてリンクとする。面白かったら芋づる式に次を読んでもらいたいから。

登録側。
テーブル構造のまんま。必須項目などはjavascriptでUIを作る。必須入力項目が多いので、少しでも便利にしておきたいところだけど、まだまだ検討材料が多い。

同人誌に限った話ではなくて。デザフェスなんかを見て感じることで。
世間とか時代とかに、もし閉塞感があるとすれば、これからは組織に頼らない個人こそが勝負できるんじゃないかと思う。

 

»電子書籍制作代行についてはこちら

profile

profile

 
doncha.net
名前:
飯田哲章
mail:
t2aki@mrh.biglobe.ne.jp
twitter:
t2akii

WEBサービス制作/電子書籍制作

検索
<<2018/10>>
 123456
78910111213
14151617181920
21222324252627
28293031

リンク

WINDOWS版サウンドノベル
おかえりください PC WINDOWS版サウンドノベル
『おかえりください』体験版

iPhone電子書籍アプリ
小説同人誌Select iPhone電子書籍アプリ
『小説同人誌Select』