color, background-colorを比較的多く使うことで流し読みの線を導いてやる。
思考過程の共有らしい。俺は別に名前にはこだわらないが、この本質にはこだわる。
/html/body/ul/li の形になる
/html/body/ul/li を全てDocumentFragment（df）にappendChildする。
HypertextNodeインスタンス（htn）を作る。これはVisitorパターンにおけるElementであると同時に、ハイパーテキストとしての本質的性質を備える。
HypertextNode#xmlは、MSXML likeにgetterを呼ぶ。
HypertextNodeは初期化時、srcを解析して複数のLinkを保持する
MicroWebdiaryVisiterインスタンス（mwv）がhtnのリンクを辿り、その都度登録されたハンドラを呼び出す。たとえばprevタイプのリンクを辿った場合、その先のHypertextNodeインスタンスにはnextリンクがなければならないので、見つからない場合例外を投げる。ハンドラ内では、この例外をキャッチする形でnextリンクを生成するコードを書くdecimal-leading-zero
def make():
gen = atomixlib.get_generator("amara")
feed = gen.create_feed()
feed.add_id(
unicode(
uuid.uuid5(uuid.NAMESPACE_DNS, URI).urn
)
)
feed.add_title(TITLE)
feed.add_subtitle(SUBTITLE)
feed.add_update(w3c_dtf())
feed.add_generator(value=u"Jintrick Stream",
uri=u"https://stream.jintrick.net/system/1.0/", version=u"1.0")
feed.add_icon(uri=ICON_URI)
feed.add_link(URI, rel=u"self", mediaType=u"text/html", title=TITLE) |
width指定なしfloatだバカヤロ。文字が緑色なのは4Suiteのドキュメントがそうだったから。大してというかほとんど意味ない。ので止めた
def now2():
return unicode(
datetime.datetime.today().strftime("%Y-%m-%dT%H:%M:%S+09:00") )
|
kasdfとてもごちゃごちゃしてる。
clear: rightしないと駄目だろう。
li[@style='clear: right']
li[@class='new-topic']
li/hrってちがうだろ。ol/hrが許されていないからやっているだけというか。
hrに決定。hr{ clear: both }。話題がガラッと変わるときに使ったり使わなかったり。決めはせず曖昧に運用するのが非常に重要。ただフロート解除したいときは必ず使うだろうな（笑）。
li hr{ border-style: dashed none none }pre[@class='prompt']はcolor: white; background: blackでどうか。
blockquoteがどうなるか、ちょっと引用してみる：
俺はHTML 4.0 Strict(そしてISO/IEC 15445:2000)の彼方にシンプルで輕快なHTMLの姿を見てゐた。最小限の記述で十分に表現が可能である形式の文書を、だ。ところが世間の人は、シンプルと云ふ事に我慢がならなかつた。意味を表現するんだと言ひ、リッチにすると言つて、HTMLをぶくぶくと太らせた。HTML 5は、リッチなHTML――と言ふより、メタボのHTMLだ。
闇黒日記 平成二十一年二月十八日より引用
pre/codeがナンセンスというのは同意できるし、実際もうやってないが、全く持って別にどうでもいい。俺なんかcaption要素でキャプションをつけたいがためにtable/tbody/tr/td/preだぜ。悪いがpre/@titleとか*[@class]でキャプション表現するくらいなら、タグスープでも何でもやってやるし、ストリクターとかモヒカン族の攻撃にだって耐えてみせる。
strong/bigの何が悪いのか全く分からないんだけど。bigに限らずfontでも何でも。
h2/i[@class]でyearとかmonthとかをマークアップして、しかもスタイルシートでi{ font-style: normal }。i要素使う理由は、要素名が小さくてスリムだからという、ストリクタからみるとふざけた理由。だが俺は大まじめだ。span要素なんか使うくらいなら、要素名1文字の物理要素の方がまし。解ってやってる分には全くダサいとも思わん。World Wideに無視される、「上等でございます」。基本的に無視すべきコンテンツだよこれは。
p{ font-size: 95% }の「意味」をここで書く。昔書いたけど。それは「あなたが最も読みやすいと思ったフォントサイズを5％小さく表示しちゃいます。頑張って読んでね。」ってことなんだよ。なめんなよホントに。
atom:content[@type='xhtml']って互換性低そうだし、でもCDATAとかエスケープ使うくらいだったら自作generatorでやる価値ゼロだし。
sub qsort{my$p=@_?shift:return;qsort(grep{$_<$p}@_),$p,qsort(grep{$_>=$p}@_)}
atomixlib.mapperモジュールはダメだ。デシリアライズするとinfosetがガラリ変わるし、何故かatom:generator要素をfeedに追加する方法がなく、amara経由で追加してもd_feed関数でデシリアライズする際に消される。
atomixlib.generator.ax_amaraモジュールのload関数を使って、atomixlib.generator.ax_amara.Atomixインスタンスを操作するのが一番。Element Treeは知らない。
root.html.head.profile、同子要素linkならroot.html.head.linkのように表現する。
xml_xpath関数とか。
For each generic identifier (element name) a class is generated that is derived from bindery.element_base.ソースコードがないと思ったらやっぱりそうだったか。要素をバインドしたとき、その要素名のクラスが動的に作られると。マルチバイトな名前ではどうなるのかね。そしてどうして態々そんなことをするのかな。
doc.xml_xpath("//*")するのとdoc.xml_xpath("/descendant::*")するのでは、処理速度に文字通り天と地ほどの差が出るんだが、師匠はなんで例とかで多用しているんだ? 実装したんなら尚更わかるだろうに。まあ例だからなんだろうけど、なんだかなあ。
amara.pushbindのおかげでつまらないfetchのために一々SAXハンドラ書く必要がなくなる。文書のDOMをメモリに保持しなくてもXPathが使えるんだから。
root[u'html'][u'head'][u'profile']って書き方もできるんだって。マルチバイトだろうが余裕。
h2:before{ content: "JintrickのマイクロWeb日記" }。
h2{ float: right }。
visibility: hidden。display: noneでは無かったことになってしまうので。
blockquote{ border-left: 7px solid #dde }。
ins, del{
text-decoration: none;
display: inline-block;
margin: 0; padding: 0;
line-height: 1.0;
margin: 0 .2em;
}
ins:before, del:before{
text-align: right;
display: table-caption;
caption-side: top;
line-height: 0.8;
border-bottom: 1px solid silver;
color: silver;
font-size: 85%;
padding-right: .2em;
}
ins:before{
content: "inserted";
}
del:before{
content: "deleted";
} |
display: inline-tableの内容でないとdisplay: table-captionが効かないと思っていたが、display: inline-blockの内容でもキャプションになってくれた。
em{ font-style: italic }でいいと思う。これは「強調」と言われているけれども、海の向こうでは何か含みのある「強調」として扱われていることが良くあるし、純粋な意味で強調したかったら俺はstrong要素型を使うことにしている。em要素とstrong要素 - 徒書はソーシャルブックマークしておいた方がいいだろう。doc.html.head.titleというコードがtitle要素の内容のUnicode値をじかに参照するなんてことが可能に。ルールを一々定義しなくてもスキーマから自明。
xpathというメソッド名はselectNodesより3倍は良い名前だ。
xml_xpathになってしまうけど、これは仕方ない。
xml_xpath関数の引数は、正真正銘の「XPath expression」だ。doc.xml_xpath("'a'")は確かにu"a"を返す。厳格主義的にはどう見ても「ロケーションパス」しか許されていなくても「引数はXPathです」と言っている仕様が結構あるのでは。
link[@rel="alternate"][@type="application/rss+xml"]でリンクしてしまう。alternate（代替）ってのがまるで意味不明だが、モダンブラウザ（笑）はこれをフィードだと認識してくれる。セマンティクス的な虚偽とユーザビリティを天秤にかけただけの話。峻別というのはそういうこと。
CSS2リファレンスを引くためのFirefoxスマートキーワード - HM weblogでGoogleのとある仕様を知り、Fxスマートキーワード用サブサイト内検索ブックマークレットを書き直した：
javascript:with(location){ assign( ['http://www.google.com/search?q=site:', hostname, '/', pathname.split('/')[1], '/', encodeURIComponent(' %s')].join('') ) };
以前の「inurl:」を使う方法は「link:」同様ほとんど機能していなかったので、とても感激している。
javascript:with(location) href='http://www.google.com/search?q=site:' + hostname + '/' + pathname.split('/')[1] + '/ ' + prompt('Search Query:', '')body { background-color: #f9f9e0; }に。目にやさしい白ってどの辺なんだろう……a[@rel or @rev]の方がlink要素より優れたphaseがある。rel="next", rel="prev"なリンクについてもう少し掘り下げてみるとしよう。
月なんてものは(今となつては)何の根據もない、ただの時間の移り變りを示すだけの記號的なものに過ぎないんだけれども、さうは言つても斯うやつて切れ目とかけぢめとかをつけられるやうにしておくのは、昔の人の智慧なのだ。やつぱり昔の人は偉いんだなあと思つた。
闇黒日記 平成二十一年三月一日より
月単位なんて不自由な鋳型だと思っていたし、今も思っているが、どうなんだろう。
個人的には日記を読み進める上で日付情報は
essentialだと思うので、日記における日付の見出しが縦幅を奪うことは許されないとは思わないなあ。実際、日付が変わると次の日が何日か毎回右に目を滑らせて確認している。
そりゃ解る。最初視線移動量がキツかったので、右のマージンを少し多めにとるように変更した経緯がある。左フロートは続くol要素（本文）の流し読みのラインを壊すので使えないし。一応俺もessentialだとは思っていて、利点と欠点を天秤にかけ済みではあるんだが、ベターな方法があればすぐ採用すると思う。「くだらないこと」には拘るから。
ちなみに利点としては、リストの途中で日付を確認したいときにしやすいとか。日付のスタイルがかなり自己主張しているし、その日の日記本文に食い込んでいるからスクロールで消され「にくい」。20も30もリストアイテムがある時は全く意味ないけど。視線移動で流し読みのラインをいったん解除するのも、そう悪いことばかりではないと思う。
body{background: rgb(99%,100%,99%)}。「日めくりカレンダー」がかすかに浮き立つ。本当に「かすかに」でしかないけど。
ownerElementが取れないのだけは何とかして欲しかった。文書オブジェクトモデルとして破たんしてる。attr.xml_xpath("parent::*")でも駄目というか、結局ownerElementを取ろうとしてAttributeError。このためamara.pushbindの魅力が半減。暇ができたらAmara 2.0の追っかけでもやるか。
ウェブ日記のファイルを一月分でバッサリ區切るといふのは「手書き」ゆゑに選ばれた、適當な、合理性・必然性の特に無い單位だとばかり思ってゐたのだけれど、違ふのかも知れない。かうしてみるとやはり人の日常生活の慣習に合せることによる學習コストの低下、「驚き」の低減、等の效果・合理性があると言へさう。二十四時間單位で區切るのも同樣。文書とは人間が讀むものである以上、さういふ人間の慣習、リズムなどは、存外に無視出來ない。
慣習とか
リズムとかに関しては、好みの問題なので関知しないことに。
p+pとli+liじゃ意味が全く違う。もちろんli > p+pも書くことができる。何の躊躇もなく余裕でやれる。ということは分かってきた。
dl > dt+ddでdtに日付のスタイルは連続性とスピード感を（僅か）失わせる。が本質は何も変わらん。Ft.Xml.XUpdate.Processorで使用するXPath変数を定義するには変数名（QName）と値の辞書variablesをこんな風に変換してexecute関数に渡す：
dict(
[((EMPTY_NAMESPACE, k), v) for k, v in variables.items()]
)
EMPTY_NAMESPACEはNoneだが、名前空間URIを与えれば変数名に名前空間を与えることもできる。そんな事例はないっつーの。li > h3だって必要ならやると思う。それがやりたくなったら別のところに書く可能性は高いけど、ここでやれなくもない。
impl.createDocument(Namespaces['RDF'], 'rdf:RDF', None)で、ソース文書の子孫要素全てにRDFの名前空間ノードを与えていたため、XSLTインスタンスの<xsl:copy-of>がそれをくまなくコピーしていた、ということがあった。
<xsl:copy-of>を使わず、名前空間ノード以外をコピーする<xsl:template>を書くという方法だった。らしい。ルート要素に名前空間宣言を与えなければいいだけなのに。
- 未だ日附變ってゐないけれども。2009-03-08T23:46:21+09:00。おはやう。
こういう事例に対応した方がいいのだろうか。日付が変わる前に一日がスタートすることは想定していなかった。そんなの想像できるかよー。
Having a weblog address ending in blogspot.com, typepad.com, etc. will soon be the equivalent of having an @aol.com email address or a Geocities website: the mark of a naïve beginner who shouldn't be taken too seriously.
own your own future
[title] { cursor: help; }みたいなのはユーザスタイルシートでやるべきで、なおかつ「カーソルを合わせるまでtitle属性なしの要素と区別がつかない」ってどうなの、と思う。実際のトリガーがhoverなのも違和感があって、（少なくとも）WindowsのUIからすればclickでツールチップが出るものに指定するのが自然なのでは。というか、cursorプロパティはUIそのものなのでWebアプリケーション以外で使わないでほしい。crosshairもhelpも大差ない。
deadspace 2009-03-08 #11より
reasonable。
cursor: helpにも一応経緯があったと思う。多分border-bottom-style: dottedでなければ良かった。というのも、このコンテンツは非説明的で、分かる人間が素早く読めることを目指しているから、そういう人にとって大した意味もないabbr/@titleなんかが下線で「注目の訴求」をやらかすと、（端的に言って）邪魔だからだ。
cursor: helpは明らかに考えなし。
Ft.Xml.Domlette.NonvalidatingReaderがDTDを読みにいっていて、色々面倒だった。HTMLのDTDのシステム識別子があるとそれを読みにってインフォセットにshape="rect"とかxml:space="preserve"が書き加えられる。
Ft.Xml.Domlette.NoExtDtdReader instead
でもフロート云々はともかく、話題變更のためのhrは全く不要だと思ふ。之は一人の人間の一つの思考の流れを表してゐて、すべては何處かで、目に見えなくとも繋ってゐる。其處に區切なんて、存在しないんぢゃないかと。
水平線は構造じゃなくてコンテンツとしてみてもらえればと。多分「変な誤解をされたくないよ」っていう意思表示があの水平線として現れてる。あとフロート解除。
max-width: 80emの指定も考えなしなので消した。
pre{display: inline-block}も、試験しているだけで消す可能性は大というか、まだ殴り書きしただけなんだよCSS。
 |
abbr{border-bottom-style: dotted}なら、それを上書きしてまでコンテンツ特性を主張する気はない。
<data> <name current="JintrickのマイクロWeb日記"> <!-- 日記の名前: name要素の子テキストに記入すると名前が変更されたとみなされる。--> </name> </data> |
import amara
def get_name(): # data.xmlより日記名を取得する
b = amara.parse("data.xml")
node = b.data.name
name = str(node).strip()
if bool(name):
raise SomeException(name)
else:
return node.current
|
- 自分専用のページ（MY tenki.jp）を持て、プロフィールを登録できます。
- tenki.jpに登録したユーザーを友だちに追加することができます。
- 天気に関する写真を投稿したり、アルバムに追加できます。
- 興味を持ったヒトコト、フォト、質問箱をお気に入りとして登録できます。
- お天気質問箱、投票に投稿することができます。
tenki.jpへのユーザー登録 ― Q.ユーザー登録を行うとできることより
質問箱は「天気に関する質問」。一方「写真」はジャンル自由だし、何をしたいかよく分らないウェブサービスだと思っていた。
しかしいつからか「コンテンツの追加」ができるようになり、当然自分の地域の「ピンポイント天気」もMy tenki.jpに追加できる。縮小版で風向きがでないけど。
混乱しやすい（私が混乱した）のは、「unicode型」と、たとえば「UTF-8文字コード列」等の「Unicodeの文字列」は「別物」ということです。
PythonのUnicodeEncodeErrorを知る - HDEラボより引用
要するにPythonうんぬんじゃなくて、「UTF-8 = unicode」みたいな誤った観念が原因なのでは。この変な「教え」を広めているのは誰だ。
//教の教祖ではなくて//を/descendant-or-self::node()/の省略形にしたエディタが死刑。
精神の子になろう!」
精神の子とかなんとかの蔑称を考えている暇に、自分で実装書けば良かったのに。標準オタクとかなのかな。
そもそも「使い分ける」という発想自体がわかってない。サブドメインを切るとか、グループごとに日記を書くとか、つぶやきをマイクロブログで書くとか、ソースコードをgistみたいなので管理するとか、備忘録をSBMで管理するとか。そういうことをやっているうちに、人間がばらばらになって、無機質になって、断片しか見えなくなって、本体がいなくなった。
意図は掴んでないけど、用意された表現に閉じ込められて画一化していくようなモデルを連想した。その辺りに今一番の危機意識を感じているのは確か。
ネットブック
という文脈で考えるなら、不幸としか言いようがない。WSVGA(1024×576)
なんて本来十分なスペックだったのだが、「ウェブ＝高解像度モニタで閲覧する」という図式が馬鹿ウェブデザイナやど素人クライアントの頭を支配してしまうのに、CSS黎明より10年という月日は十分すぎるほど長かった。
すべてのクラスには__bases__という隠しフィールドがあるので、そこに任意のスーパークラスを作って追加する、という
結論が先に来ているのが偉い。
やはり退屈で紛らわしい、要求を満たしてくれないウェブサイトは誰も見たくない。同じようなウェブサイトはいくつもありますから、ユーザーはすぐに別のサイトに移動してします。どうしてなかなかアクセスが増えないのか。増えないどころか逆に減っていく一方だと嘆かれる管理者もたくさん見えることでしょう。原因はいろいろとあるでしょうが、根本的な問題はやはり「ユーザビリティ」の欠如にあるのではないかと思います。
ｅふぉーらむ：ガイドライン－ウェブ・ユーザビリティの概要－ウェブ・ユーザビリティより引用
「退屈で紛らわしい」なんたらというキャッチフレーズはどこかでみたことがあるが、それはともかく、アクセスが増えない根本的な原因はユーザビリティの欠如ではない。それを知らないウェブ制作者はいないと思っていた。ユーザーはユーザビリティなんて滅多に気にしない。他のサイトより良質なコンテンツを利用さえできれば。もちろん同じようなコンテンツであったなら原因の一つにはなるだろうが、たとえばブランドイメージ等の方がはるかに大きな要因だろう。
ちなみに強調部分はspan[@class="emphasis"]だったのでユーザースタイルシートが利かない。
どうやら俺はネタに釣られたらしい：
<span class="emphasis"><span xml:lang="en" class="n-eng">HTML</span>の本質を理解し、</span>正しい運用と技術の習得に心がけさえすれば、それで十分ユーザビリティに配慮したウェブサイトになるはずなのです。
AttributeError喰らったかわかりゃしないくらい。
日本人が会議で目標について話し合うと、理念とか希望が挙げられ、実質的に何の意味もない形だけのスローガンが立てられる。つまり達成できたのかできていないのか評価することはできず、具体的に何が改善されるのかも良く分らない。必ずと言っていいほどそういう方向で纏まろうとするから、実質が欲しい人間は待ったをかけることになる。俺は毎年度この煩わしさに悩まされている。
では彼らの「目標」とは何なのか、と少し考えてみた。「我々はこういう偉いスローガンを掲げていますよ」ということを対外的、対内的に示すのだろうが、その退屈なスローガンが一体何を改善するというのだろうか。「個人目標」を立てろというと、「～を頑張る」とかいう馬鹿もいて、それがとても良いことだと思っているらしい。頑張るのが目標か。
到達すべき状態と、それに向かうためのベクトルがある。goalというのは当然前者のような状態のことであって、ベクトルではない。しかし「目標」は、ベクトルでもあり得るということだ。ベクトルならまだいい。単なる力（ちから）だったりすることもあって、こうなるともう、到達すべき状態すら存在しない。何かを頑張ってどこかに向かっている、ただそれだけを言うための「目標」だ。
li/h3どうよ。という話。
li/hならむしろ素敵なんだが、li/h3はどうも引っかかる。div/h3と何が違うの。と自分に問い詰める。
三宅氏が自分の勝手な解釋に基いて居丈高に他人を罵る惡質な人間の一人である事實が今囘、明かになつた訣だ。
というか、単にまた法令云々の被害妄想を膨らませて、「加害者」に正義の鉄鎚を振り下ろしたのだと思った。
li/h3について
li/h3みたいなのは一律でli/dl/dtにしている。タイトル（term）に内容（description）を加えるという形。これはタイトルを文書見出しというよりはキャプションとして捉えているため。h系要素は文書全体に対する見出しだと考えているので、レンダリングなどに問題はなくとも使うのにはかなり抵抗がある（アウトラインを抜き出したとき前後のリスト項目がどこかへ行ってしまう）。
どうも。liが（前後で関係しているかもしれない）コンテンツの断片だとすれば、liの中身がそれで一個の「サブ文書」を形成していることもあるはず。するとサブ文書を抽出して考えればli/h1ということになるのだけれども、コンテクスト上「最も重要な見出し」にはならないので、やむを得ずli/h3としている、というところに引っかかりがあるということは確認できた。
body/div[h1[@class='blog-title']]/div[h2[@class="date"]]/div[h3[@class="article-heading"]]みたいな形式は良くあるけれども、この最下層の「div」の形式を、デフォルトスタイルシートの強みを持ち、シンプルなテキスト内容のみでも違和感のない「li」に変更したに過ぎない。そのように個人的には捉えていて、そうすると形式的には（あくまでも「形式的」には）各リストアイテムはh3を乱暴に省略されていると考えることも可能だ。その省略が不作法だが、カオスなんだからそうなるのがむしろ自然というか。表現が難しい。
ところでこの形式において「アウトライン」って最初から無いのでは。日付以外。だったらh3で抽出されるアウトラインから漏れた部分は、もともとアウトラインの抽出という手法ではアクセスできないものだろうから、li/h3で失うものではない。説明できているかどうかは全く自信ないが。
私が歴史的假名遣を使用する理由は、要は「現代仮名遣い」の説明には納得がいかない、といふことである。
li/dl/dd[preceding-sibling::dt[a]]でリンク先にコメントをつけてもいいし、あくまで散文的にやってもいい。
ミリ秒単位で速くなろうが、俺にとってFirefoxの優位は微塵も揺らがない。最もシンプルな形から自分に必要なものだけを組み入れることができることの素晴らしさ。敷居の高さを感じないのなら、これが最高。押し付けられた「多機能」をどうやって隠ぺいしたり無効化するかを考えるより、アドオンを一つずつ導入していくほうが遥かに楽。2から3への移行では再導入の手間すらほとんどなかった。
それと同様にスマートキーワードの存在が大きいかな。良く考えてみると。
p{
margin: 0;
text-indent: 1em;
}としてみた。この方がこの形式に合っている。
Jintrick氏がagenda (Jintrickのメモ帳)に
agendaを元に体系化した文書は、Jintrick Archivesに纏める予定とする。と書いてゐるのは、俺が「ここ」でやらうとした事を同じやうにやらうとしたのだつた筈。
「ブログ記事」を体系的なサイトの記事に編集するのがどうも億劫で。それができれば素晴らしいと思うのでやりたくない訳ではない筈なのに。でもこの形式で垂れ流したなら、まとまった一つのアイデアとして認知されにくいから、「勿体ない」ということでサイトの記事に編集する動機も強くなると思うので、その辺りを自分に期待。
そして現職、近くにすわっている伝説的スーパーマネージャーがなんと「Firefoxでカスタマイズして喜んでいる奴はですね、結局ガキなんですよ」と言いながらIE8を使っているではないですか。
わろた。
dl/dd[preceding-sibling::dt[1][q[@cite]]]で引用元に言及するテストなんでblockquote[@cite]（あるいはq[@cite]）がリンクという発想になるのかわからない。
発想したわけではなくて定義だから。リンクとはリソースとリソースの間の関係のことである。ハイパーリンクの定義との違いに留意されたい。
自分でこの辺りきちんと纏めた記憶がないので、W3Cはiframeをリンクと言っているか？ - 徒書を紹介。
需要があればaにrel-quoteとか作ればいいレベルだと思う
俺はリンクの種類が分かればどっちでもいいけど、仕様書には「引用元はcite属性で示せ / UAはユーザがそれらを利用できるように」せよだかすべきだかみたいなことが書いてあった。と思う。
a[@rel="bookmark"]が必要なのかどうか良く分らなくなってきた。agendaでも結局パーマリンクという考え方は取り入れなかった為、更新ページ（フロントページ）は見出しの一覧のみで記事内容は載せなかった。
agendaは形式的にはブログではないつもりなので、更新ページにコンテンツを載せるという手法に倣わなかった。だが実質的にはブログ化していて、こことの使い分けはもはや難しくなっているが、ブログっぽい形式で何かを書きたくなることはあるはずだ。
とりあえずメモ。
まーとにかく話好きなご主人なので、一言聞けば5分くらいコーヒーの話をしてくれる。
なお、このサイトはコンピュータに損害を与える可能性があります。 宜しくお願いします。
もう論理があまりに粗雑過ぎて反論する気も起きないんだけど……。と呆れたことを表明しつつ結局反論を書くみたいな人はどうも好きになれない。
caption-side: bottom的な見せ方ならフロート解除しなくてもそれほど違和感ないみたい。素晴らしい。できればフロートは生かしたいので今後倣う。
.floatright{ clear: right }一種のサポートセンターなのです。フリーダイヤルの窓口なのです。
個人的には、よく新しいサーヴィスに登録して管理すべきIDとパスワードを増やせるなーと。最近は管理する事が億劫で、新しいサーヴィスに手を出す氣がしない。
これ、セキュリティがらみの話だからあんまり書きたくなかったんだけど：
という人は他にいませんか。
/*/content:xml-contentにappendChildされるだけ。xmlns:content="http://purl.org/jintrick/Personal/2009/01/29/content/"。
しかし、反論出來る可能性のある事を言ふのは當り前であり、反論可能性のある意見に對しては反論するのが議論の最低のルールだ。
1か0かだ。とまあ、俺はそう信じているのでちょっと凄いと思った。ちなみに、吸いたくなったら人からもらえばいい「的」な考え方は、一部の人が内心凄くうざがっていて、陰口叩いている人が結構いた。俺はもう完全にやめたので今は無縁だけど、そういう友人には「自分で買えよー」と言っていた記憶はあるが、別に嫌ではなかったな。「はてサヨ」みたいなイナゴが食いつきそうなネタだね。
たとえば要素内容をaタグで括ってアンカーにしたいケース（例：XML断片）では次のような手順を踏む：
xml_childrenで参照しておき（Pythonのリスト）
xml_clear()で要素内容を削除
xml_append_fragment('<a href="url" />')で「aタグ」を挿入
xml_append(node)で追加する
xml_append_fragment("<tag />")を使わない場合、xml_create_element(QName, 名前空間)でa要素を生成してhref等の属性ノードをぶら下げてからxml_append(node)することになるので、結構コードがかさむ。
具体的なコードはPythonコードを参照。
| 変更前 | 変更後 |
|---|---|
<h2 class="date wednesday">
<i class="day">1</i>,
<i class="month">April</i>,
<i class="year">2009</i>
</h2> |
<h2 class="date wednesday">
<a href="./2009/0401.html">
<i class="day">1</i>,
<i class="month">April</i>,
<i class="year">2009</i>
</a>
</h2>
|
h2 = doc.html.body.h2
df = h2.xml_children
h2.xml_clear()
h2.xml_append_fragment('<a href="./2009/0401.html"></a>')
a = h2.a
for node in df:
a.xml_append(node)
|
surroundContentsメソッドを定義してしまってもいい:
class range_interface(bindery.element_base):
def xml_surround(self, frag, tagname):
df = self.xml_children
self.xml_clear()
self.xml_append_fragment(frag)
parent = self.xml_children[0]
for node in df:
parent.xml_append(node)
Range風のインターフェイスを与えたい要素型に、このrange_interfaceというカスタムバインディングクラスを関連付けてamara.parseする:
XHTML_NS = u"http://www.w3.org/1999/xhtml"
amara.parse("eve.xml",
binding_classes={(XHTML_NS, u"h2"): range_interface})
Pythonはメソッドオーバーライドロードが使えず、条件分岐はエッセンスの説明に向かないので、とりあえずサンプルコードは「タグ」を引数に取るものだけ。
こうしてバインドすると、先述のPythonコードはh2.xml_surround('<a href="./2009/0401.html"></a>')と書けるようになるが、全ての要素型で使えるようにするための良い方法が見つからない。
The internet: an advance in communications technology enabling people you don't know to send you messages you don't read.
最初スパムメールのことを言っているのかと思ったが、どうも示唆的だ。
calendar.month_nameの月名リスト（["", "January", "February", ..]）しか使っていないから、自前で同じリストを用意した方が速いだろうな。えらく熟考した割に全然機能がない。この過程は愛すべきだろう。
ひどい人間になると、すさまじくどうでもいい感想を書いただけの記事でトラックバックまでしてくる始末である。
はてなブックマークに保存したブックマークをはてなブックマークを訪問することなくブラウザから直接参照
。さすが、はてなブックマーク。GUIにもちょっと期待。ウェブページとしてはアレなアクセシビリティを誇ったはてなブックマークだが、アドオンとなれば話は別。俺には、はてブのハイパーテキスト版はオマケでありアドオンのような形式を取る前段階のベータ版に見えていたので、全然批判する気にならなかった。正確には、一度書いたけど公開するのをやめた。
ただ、素人ユーザーの意見とか感想とかを求めるのではなくて、頼むからきちんとしたユーザビリティテストをやって欲しい。はてな的に見れば「はてブユーザー」の意見では駄目だし、もちろんテスターとしても全く相応しくないはずだ。
とこんなところに書いていても仕方ないので、自動で（笑）トラックバックを送れるagendaに書いてみた。
ここを真似したと明言してる人だってみんな何らかの媒体と使い分けていて、一つの「媒体」として真似してるだけ。
body直下に
<h2 class="date friday"> <i class="day">3</i> <i class="month">April</i> <i class="year">2009</i> </h2>ような日記見出しの構造体あるとする。
import calendar
class calendar_interface(bindery.element_base):
def date(self):
loc = 'string(descendant::*[@class="%s"])'
y, m, d = (
int(self.xml_xpath(loc % "year")),
calendar.month_name.index(self.xml_xpath(loc % "month")),
int(self.xml_xpath(loc % "day"))
)
return datetime.date(y,m,d)
|
このとき、h2.date()でdatetime.dateオブジェクトを取得するためのcalendar_interfaceというカスタムバインディングクラスをxhtml:h2に登録してamara.parse。
「だからamaraはDOMを実装するツールなんだってば」
h2_calendarは日記の日付を表す概念で、HTMLのh2要素としてシリアライズされる。次のメソッドがある。
date()
year()
unicode(h2_calendar.date().year)と同じ。ちなみにXML的に「物理的に」アクセスすると、h2.xml_xpath("string(descendant::*[@class='year'])")
month()
unicode(calendar.month_name[h2_calendar.date().month])と同じ。
day()
unicode(h2_calendar.date().day)と同じ。
ol()
pack()
(h2_calendar, ol_diary)のtupleを返す。
parmalink()
ol_diaryは日記内容を表す概念で、HTMLのol要素としてシリアライズされる。
update(new_ol)
append(ol)
ol/liを追加する。
h2()
reverse()
全ての要素が持っているもののうち、主なもの：
xml_parent
xml_children
xml_xpath(expression)
xml_remove_child(child)
list.reverse()はNoneタイプだった。
class future_interface:
def __get_xml_last_child(self):
chi = self.xml_children
return chi[len(chi)-1]
def __get_xml_first_child(self):
return self.xml_children[0]
def __get_xml_type(self):
return str(self.nodeType)
def __get_xml_qname(self):
return self.nodeName
def __get_xml_namespace(self):
return self.namespaceURI
def __get_xml_prefix(self):
return self._prefix()
def __get_xml_name(self):
return (self.namespaceURI, self.localName)
def __get_xml_following_sibling(self):
par = self.xml_parent
try:
return par.childNodes[self.xml_index_on_parent+1]
except IndexError:
return None
def __get_xml_preceding_sibling(self):
par = self.xml_parent
try:
return par.childNodes[self.xml_index_on_parent-1]
except IndexError:
return None
def __set_immutable(self, value):
raise AttributeError("read-only.")
xml_last_child = property(__get_xml_last_child, __set_immutable)
xml_first_child = property(__get_xml_first_child, __set_immutable)
xml_type = property(__get_xml_type, __set_immutable)
xml_qname = property(__get_xml_qname, __set_immutable)
xml_namespace = property(__get_xml_namespace, __set_immutable)
xml_prefix = property(__get_xml_prefix, __set_immutable)
xml_name = property(__get_xml_name, __set_immutable)
from amara import bindery
bindery.element_base.__bases__ += (
future_interface,
)
|
list.__reversed__()でいいのか。文法的に何かあったっけ?
class future_interface:
@property
def xml_last_child(self):
chi = self.childNodes
return chi[len(chi)-1]
@property
def xml_first_child(self):
return self.childNodes[0]
@property
def xml_type(self):
return str(self.nodeType)
@property
def xml_qname(self):
return self.nodeName
@property
def xml_namespace(self):
return self.namespaceURI
@property
def xml_prefix(self):
return self._prefix()
@property
def xml_name(self):
return (self.namespaceURI, self.localName)
@property
def xml_following_sibling(self):
par = self.xml_parent
try:
return par.childNodes[self.xml_index_on_parent+1]
except IndexError:
return None
@property
def xml_preceding_sibling(self):
par = self.xml_parent
try:
return par.childNodes[self.xml_index_on_parent-1]
except IndexError:
return None
|
body.reverse()をテストしたらうまくいった。
body.reverse()したらこんどは何も起こらず、バグかと思ってコードを追った。
list.reverse()の動作を期待してしまう。
sort_by_date(reverse=False)を定義。降順にしたいときreverse=Trueでinvoke。
node.xml_surround('<a href="foo.html"/>')。何をしているのか一目瞭然。超「精神の子」だ俺。
chi = ref.xml_parent.xml_xpath("*")
try:
next = chi[chi.index(ref)+1]
except IndexError:
next = None
i = chi.index(ref) prev = i and chi[i-1] or None
reversed(list)で逆順のイテレータか。
自分にとつて不都合な事であつても、眞實ならば認めなければならない――さう云ふ意識から眞實を追求するか何うか。そして、さう云ふ眞實をこそ闡明せよ、と云ふ主張。
<!--パーマリンクのフォーマット。date.strftimeメソッドの引数となる。
URLの変更を伴うため再構築不可（仕様） / current属性値を直接編集すれば以降は反映される-->
<parmalink_format current="./%Y/%m%d.html" />
はてなブックマークFirefox拡張をインストールしてみた。
まず「ユーザー」と「はてなブックマーク」との架け橋（UI）はツールバーとステータスバーがこれを担っている。デフォルトの設定ではポインティングデバイス依存で、代替手段が提供されないが、ツール→はてなブックマークから色々設定を変更できる。ここまでは別にいい。しかしキーボードショートカットを変更する手段がまたポインティングデバイス依存なんだよ。こんなUI見たことも聞いたこともないよ。入力欄を「クリック」すると（「アクティブ」じゃあない）、「キーボードを押して、ショートカットを設定します」というモーダルダイアログ系がポップアップされる。これには「キャンセル」ボタンがついていて、押すとこのポップアップ表示が消える。問題はショートカットの入力を受け付けるのは、このダイアログがポップアップされているときだけだという事実。俺はこんなUIをみたことがない。ポップアップして警告しなければならないのは、設定ダイアログの最後に小さく表示されている「ショートカットの反映に、ブラウザの再起動が必要な場合があります」という文句、それだろう。
はてなブックマークサイドバーは、一部期待された動作をしない。現在表示されているウェブページのタブをドラッグドロップしても何も起こらん。だったら、フォルダのアイコンを用いるべきではない。これは、何かを格納できることを示唆するときに用いるべきものだ。タグはツリー構造のデータでないから、これにフォルダのメタファを使うべきかどうかも、俺には疑問。ユーザビリティ的にも多分間違いだろう。期待されている動作と異なるからな。Microsoftがフォトギャラリーでやっている方法の方が概念をうまく表現できている。
ティム・ガン風に言うと、「洗練されてない」。
キモイだのなんだのと、俺の嫌いなイデオロギー臭がする。巻き込まれたくないんだ。
新しいインターネットを体験させるUIを素人に設計させる愚。
h2.textContentはunicode(h2)と書く。たとえば4月1日の日記のh2なら:
>>>unicode(h2) u"1, April, 2009"になる。
>>>import datetime >>>datetime.datetime.strptime(u"1, April, 2009", "%d, %B, %Y") datetime.datetime(2009, 4, 1, 0, 0)
calendar.month_nameを使う必要がゼロに。ただしXML的な処理を放棄したので構造の変化には弱くなったが、要素名とかクラス名の変化からは逆に解放される。日付フォーマットを設定値にしておけばいいのか。
processing-instruction(name)というノードテストを思い出し。
amara.create_documentはバギーなのでamara.parse(string)を使おう。こっちの方が視認性がいいしな。
deliciousのFirefoxアドオンを導入してみた。
新しいインターネットとはよく言ってのけたもんだよ。
引用元を記す部分について。
<blockquote> <p>吾輩は猫である。名前はまだない。…</p> </blockquote> <ul> <li><cite>夏目漱石『吾輩は猫である』</cite></li> </ul>――何うだらう。
多分p要素を使うより良い。ぐだぐだ理屈を述べても仕方ないから、自分自身のsafariユーザースタイルシートを例にすると、内容の意図を読むべきp要素には明朝体、リスト項目他の部分にはゴシック体を指定してある。フォントはどうでもよくて、ともかく区別することで内容を読むスピードを上げている（つもり）。
いままでp要素を使っていたのは、引用文のプロパティ的な要素としてではなく、文章の流れの一部として記述していたから。
今後俺はp/citeからul/li/citeに変えるけれども、ただ形式を置き換えるのではなくて、文章を書く意識を変えるということになるわけだ。
官僚でも何でもない一般人が、官僚の自畫自讚を無批判に受容れ、彼等を賞讃してゐる。
<xsl:template match="html:ol|html:ul|html:table|html:dl|html:body|html:tr|html:thead|html:tbody"> <xsl:copy> <xsl:apply-templates select="@*|html:*" /> </xsl:copy> </xsl:template> |
li/h3。liは混合内容なので、カレントノードリストを乱暴に要素ノードに変更することができない。だが注意深く見ると、h3の前後は改行一文字しかないことが分かったので、ちょいと乱暴だけど専用のXSLTテンプレートを書いた。色々なパターンがあるかと思ったのでtextノードの内容は変数にバインドしてみたが、意味はない。
<xsl:template match="html:li/text()"> <xsl:variable name="cnt" select="string()" /> <xsl:if test="not($cnt = ' ')"> <xsl:copy /> </xsl:if> </xsl:template> |
exceptions.StandardErrorでFt.Libモジュール内の例外を拾えていなかった。ユーザー定義例外はexceptions.Exception派生なのに。なんで俺はStandardErrorで全部拾えると思ったんだ? 変な知識かじった?
「正しい」とは「正しくない」事なのである、と云ふ逆説。どこからともなくこの逆説が流れてきて、「草」を洗脳していく。で、考える「草」は訳が分からなくなって鬱になったり馬鹿になったりする。
そう来ると思った。こういう切り返しに名前をつけたい。
#5/3/2009#
Month(#5/3/2009#)。もっと適当にやるならMonth(DateValue("9年5月3日"))とか。
およそ人間的とは言えない満員電車に押し込まれて毎日通勤し、機械仕掛けの時計の時間に追い立てられ、効率優先・利潤優先の要請に追い回されて、プライベートを楽しむための方便として仕事に行くはずだったものが、仕事の疲れをとるだけのプライベートになってしまう本末転倒。老後の心配の方に重点がシフトして「今を生きる」ことがなおざりにされ、生きる楽しみの大切な一つであるはずの食事までもガソリン補給のようなものになり下がる。翌日起きなければならない時間のために就寝時間が決められ、すぐに寝付けなければ「不眠症」ということになってしまう……。このような現代人の生活に疑問を抱かないことを「適応」と呼び「正常」と見なし、そこに戻すことを治療のゴールと思い込んでいる現代の医療も、「うつ」の発する警告を真摯に受け取る必要があるでしょう。
Amazonの1-Clickが、明らかな効率の改善
だというが……
このアイデアが実装されるまで、インターネットショッピングでの支払いは面倒なものだった。クレジットカードの種類や番号を入れ、有効期限を入れ、ときにはセキュリティコードも入れなければならなかった。さらに送り先の住所や氏名、電話番号を入れ、確認をしてようやく手続きが完了する。この手順を本当にワンクリックだけにしてしまったのがAmazonのアイデアだ。事前に登録しておけば、所定のカードでの支払いが行われ、所定の住所に商品が届けられる。改善すべき副作用があるとすれば、買い物をしすぎてしまうことくらいだろう。この1-Clickは、あきらかに効率の改善であり、ユーザビリティを高めたやり方だといえる。
Amazonで買い物をしたことがあれば分かるが、ログイン（sign in）していれば事前に登録したクレジットカード番号等々の様々な情報は再入力しなくて済む。そして1-Clickは、ログインしていなければ使えない。一方「カートに入れる」式の標準的な手法なら、ログインは事後でいいし、しなくてもいい。創造的
な「1-Click」と、標準的な
「カートに入れる」、どちらが一般に優れているかは明らかだと思う。ヘビーユーザーにとっては、「1-Click」の方が便利なこともあるということ。
前後から風が出てくる温風乾燥機は、創造的といえる。
それまで公共のトイレにあった温風乾燥機は、上から風が来るだけなので風を強くすると水が飛びやすく、反対に風を弱くするとなかなか乾かないものだった。そこで、担当者は強い風を両側からあて、そこに手を差し込む形を設計した。
「素早く乾かす」等のgoalに対して問題点が上がり、それに対してアイデアを練るというのは、ハードウェアにおいてはありふれたユーザビリティ改善の光景だろう。
UsedRange.Find("キーワード").CurrentRegion.Select。これは使える。
コンバットの効果が切れる半年後のために設置場所をメモ。
*1 HTML5でリニューアルしましょう！的なセールストークを含めて
ざっとみたところ、Firefox3.5の新たなCSS対応はこの辺か。
おれにはほぼ関係ないな。パフォーマンス下がる要素ばっかりだ。むしろあとの独自拡張プロパティとかmedia queryとかが関係大。
固定幅レイアウトには固定幅レイアウトのメリットがあると思っています。特に大きなビジュアル（ブランドイメージを訴求するための写真など）を重要な要素として使用しているサイトの場合、リキッドレイアウトだとデザイン上「おさまりが悪い」状態になる可能性が高いと言えます（写真自体が、ベクターデータではなくサイズ固定データだからです）。
「おさまりが悪い」って何なんだ?
きれいな画像を固定幅にきっちり「おさめて」ブランドイメージを植え付けるのは、ユーザのためじゃない。
input[@type="password"]の使用を忌避することで解決されるだろうことが気がかりといえば気がかり。特に個人的に使ってるパスワード入力スクリプトが動かなくなるのが困りもの。今後それを使わない方向で再検討する必要があるかもしれん。
input[@type="password"]上でESCキー押下時に見えたり隠れたりするユーザースクリプトでも書くか。
var nl_input = document.getElementsByTagName("INPUT");
var i = nl_input.length;
while(i--){
var input = nl_input.item(i);
input.type == "password" && input.addEventListener("keydown", test, true);
}
function test(evt){
var e = evt.target;
if (evt.keyCode == KeyEvent.DOM_VK_ESCAPE)
e.type = e.type == "password" && "text" || "password";
}
KeyEvent.DOM_VK_ESCAPEがundefinedだった。気持ち悪いけど値（27）でいいか。
デザイン目的のマークアップて良くわからんが、その辺のマークアップは外部スクリプトでやってるからソースには影も形もないはずなんだが。DOM Inspectorで見たものはソースというの? 素で知らん。「DOMソース」みたいな言い方は見たことがある。
We highly recommend that Amara users start migrating to Amara2.
テキストボックスに文字列を入れて[Enter]キー/[Return]キーを押すとどういう結果になるか（どんなフィードバックが返ってくるのか）、というイディオムは、Webアプリケーションの世界では限定的ではない（様々なパターンがある）ように思います。何らかのサブミット（データの送信）が実行されるのだろうなあという類推はできますが、サブミットした情報がどういう形で使われるのかという具体的なイディオムは、操作子の中でしっかりと文脈提示されているほうが、よりユーザーに対して親切だと思うのです。
まったくもって。ウェブサイトのフォーム部品上で迂闊にEnterなんか押したくないと思うのが普通だよ。
商用サイトを使って何かを買おうとして、初めてサイトを訪問しました。 このとき自分は、「お店」の「お客さん」の気持ちでサイトを見ていました。 リアル店舗のときのように、 お客さん扱いしてくれるページの作りが当然だと思っていました。
このような代替スタイルシートを作成する場合の留意点ですが、ユーザースタイルシートが存在する場合はそちらを優先させるべきなので、各プロパティおよびその値に「!important」と書かないようにしましょう。
受益者負担の原則をどうするか。「受益者」は車を運転する人だけではない。大西 宏のマーケティング・エッセンス:車を持たない人には、高速道路無料化は関係ない? - livedoor Blog（ブログ）。これ適当にググったらすぐでてきた。中身は読んでないが大筋で同意だ。一々説明するまでもねーよ。
雇用の問題。どうしてそれが「問題」なのだ。料金所がなくなると職を失う人がいる。それを「問題」と認識するなら労働市場を管理でもしろよ。国ができるのは失業保険等を整備することだけだ。まあこの法人にとっての問題かもしれないが、そんな論点で議論が起こるわけがない。
民主党の政権になれば生活が楽になりますよ、と盛んに言っている。もっと言えば、それしか言っていない。
今、最も政治がやらねばならないことは、いかに国民の政治不信をなくすか、つまり、いかに政治を透明にするかだ。
だからこそ、私は民主党にマニフェストの冒頭で「自民党は、政治をきわめて不透明にしてきた。どんどん政治不信が募り、ひいては自民党不信が募った。我々が政権を取ったら、政治を徹底的に透明化する」と言ってほしかったが、全く謳（うた）っていない。
代わりに、「子ども手当」、「高校の無償化」、「暫定税率廃止」……と、いろいろ並べている。
それでいいんだよ。「政治を徹底的に透明化します！」と宣言したとしよう。しかしどうやって「政治が透明化したか否か」を国民に示すのだ。その公約を達成できたかどうかを、どうやって国民は判定するのだ。そんな曖昧な公約はこれまで同様、口先三寸でどうとでも誤魔化せる。だから、せっかくマニフェストが注目されている今そんな公約を掲げるのは愚の骨頂だ。今すべきは、短期的には景気対策と官僚主導の政治からの脱却、長期的には「小さな政府」化と少子高齢化に歯止めをかけることであり、それらを実現する為の施策の内、国民に直接利益のあるもの、実行結果が見えるものをマニフェストとして提示し、広く国民に認知させることだ。そして政権を取ったら、速やかにそれを実行する。これが政治不信を解消するための最適な手段だと俺は考え、疑わない。
「リキッドレイアウトは高解像度ディスプレイで見ると文章がびよーんと伸びて読みにくい」という批判に対しては、ユーザー側、製作者側、それぞれの観点で2つの反論が可能。しないけど。
ある知的障害者が自身の障害に関して情報サイトを運営していました。そのサイトの情報は質がとてもよく、情報を求める人が多く訪れるようになり、そこへリンクするサイトが増えました。
それは良かった。
すると、知的障害の人を中傷する荒らし（極めて悪質な）が驚く程大勢やってきました。
「やってきた」とはどういうことだろう。物理的に「やってきた」のなら警察に通報しなさい。単にアクセスしてきただけでパソコンの前で悪口を呟いているだけなら放っておけばいい。掲示板に「やってきた」のなら、掲示板にアクセス制限をかけるなりすればＯＫ。
管理人は元々障害に関しての情報が広まってほしいと願ってサイトを開設した訳で、勿論インターネットの利点を最大限に利用したいとの考えでした
なるほど。
が、一時は「無断リンクお断り」を明示、「リンクの際には連絡を必要」としましたが、それに関しての批判（説明不要ですね）が寄せられたためサイトを会員制に変更して運営を続けました。
悪くない判断だ。無断リンク禁止を宣言しても、悪意の「荒らし」のアクセスを防ぐことはできないのだから。「荒らし」にアクセス制限をかければもっと良かった。
荒らしはなくなりましたが、代わりにアクセス数が急激に減りはじめました。会員は既に障害についての知識がある方のみで、本来の開設趣旨と違うただの「集まり」に過ぎない状況になりました。（このサイトは、理由は存じませんが閉鎖されたようです）
「荒らし」にアクセス制限をかければよかったんだよ。会員制の面倒な手続きが問題だったのだろうから。
時たま顔を出すご自身の性格にも少し目を向けた方がよろしいかと思いますって何だ。思い当たるのは自己紹介ページに自分の写真を載っけてることくらいだが、こういうの「顔を出す」っていうか?
まずはトップページ。情報の分類や配置を考えることによって、多くの情報へのナビゲーション機能を備えながらも、ほとんどのユーザにとって2画面程度の大きさに収めて、使い勝手を高めています。
しかしながら、現在の Web では、ユーザは検索エンジン等を経由し、トップページ以外からも来訪するケースが多いため、トップページのみ秀逸であっても不十分です。
ジェトロでは、下層ページにおいても、階層ごとにトップページを設けたり、ナビゲーションやページレイアウトを共通化して、Web サイトと今開いているページの関係性を把握しやすくするなど、しっかりとした作り込みを行っています。
もちろん、画像に代替となるテキスト情報が設定されているか、｢こちら｣などの意味のない言葉にリンクが貼られていないか、リンク切れを起こしていないか、などといった、基本的な注意点もきちんとカバーすることで、全体として、高いレベルのユーザビリティを実現しています。
再輸出の可能性がある貨物の再輸出における関税払い戻し手続きについて - アジア - ジェトロを見れば分かるが、サイト構造の深さがこの行政法人側の都合で決められているっぽい。ユーザーの視点で作ればこんな深さにはならない。
ママチャリで通える距離ならママチャリでいいが、そうでない場合について。
舗装路だけなら格安のアルミフレームにカーボンフロントフォーク、Deore LX以上のMTB系コンポーネント（ディスクブレーキ）、バーハンドル＋エルゴグリップ、泥除け、ハブダイナモ、ビンディングペダル、700×28c以下の細さのスリックタイヤを履かせるということで、見積もりを出してもらう。サドルは最低価格の比較的肉厚で幅の狭いものをつけてもらって、後々自分に合ったものをつける。完成車は買わない。
砂利道等の悪路が混じる場合は、カーボンフロントフォークとハブダイナモは止め、シクロクロス用のホイールとタイヤを履かせるということで見積もりを出してもらう。
毎日3問ずつWebサイト制作 ・ユーザビリティに関する○×問題をつぶやきます。はいいんだけど、
Q.ある金融系サイトの事例。アクション導線として「資料請求」ボタンだけを置いた場合よりも、「お問い合わせ」と「資料請求」の2つのボタンを並列に並べた場合のほうが、「資料請求」ボタンがユーザにクリックされやすかった。○か×か？
A.○：【解説】「お問い合わせ」ボタンと並べると「資料請求」が比較的簡単に感じられ、行動に結びつきやすくなるようです。これは俗に「コントラスト効果」と呼ばれる現象で、相対的に物事を捉えがちな人間の認知特性を反映しています。
まあ確かにその性質はユーザビリティと関係があるが、ユーザビリティに応用していない。
この製品にはリチウムイオン電池が使用されています。この電池は交換できませんが、くり返し充電できます。通常の使用では、最大約400回充電できます。とある。ちょっと心許ないなあ。
ミュージックプレーヤー（私の場合はwillcom 03）とのペアリングを解消（要するにwillcom 03のbluetooth機能をoff）にすると、音量バランスは正常（左右均等）になった。という情報もあり。
俺たち選ばれし者が愚かな民衆を善導（？）するのだ！、とでも考えて居るように見える。
伝えるべき情報の本質は文章そのものである、が正しいとすれば、前述のように『第一節 渓流とは何か』と書いて措けば済みます。 これを Hn でマークすれば良い。
ISO や JIS が業界のための規則であるように、HTML 仕様が Web 制作業界のための規則になるのは已むを得ないのかも知れません。マニア、専門家、業者 三位一体（？）のセクショナリズムで決まって行き、私のような素人（利用者、消費者、顧客）からはどんどん遠ざかる。でもね、それで良いのだろうか。
正しいといふ感覺は他人に押し付けるものではありません、自分の正當性は自分で判斷し、その「正しい」を聞いた者はその人自身が正しいか否か判斷をするものです。
モバイルSuicaサービスが可能な時間は4:00～翌日2:00です。時間をお確かめの上、再度実行してください。って言われたよ。失笑。これが日本のIT商売。
この度はモバイルピコプロジェクター（0901SAA）をお買い上げいただき誠に有難うございます。また今回のキャンペーンにご応募いただきありがとうございました。お客様から頂きましたご意見は今後の商品開発に活かしてまいります。パソコン接続ケーブルを同封いたしますので、ご活用ください。
株式会社 東芝
あと、「文章を書き直す」って考えちゃった人、ダウトですよ。文章を書き直さなきゃならないような、HTML ってなんなんですか？って言われますよ。
「文章を書き直す」って考えちゃった
わけじゃないけど、書き直すのはありだと思う。文章が所与であるなら「書き直す」と切り返すのはナンセンス極まりないけどね。
HTMLってなんなんですか？
ってのが気になるなあ。そう言われたら、文章所与を前提条件とはしない何かだって切り返すけど。風呂敷広げすぎじゃない?
長らく検索バーを非表示にしてロケーションバーで代替してきたが、やめた。スマートキーワードで毎度検索エンジンを選択するのが結構面倒くさくなってきた。Google (US) が多いし。
javascript:(function(){
var d=document, u=d.URL, t=d.title,
d=d.implementation.createDocument("","",null),
a=d.createElement("a"),
sr=new XMLSerializer();
a.setAttribute("href",u);
a.appendChild(d.createTextNode(t));
prompt("[タイトル]:\n"+t+"\n\n[URL]:\n "+u+"\n\n[HTMLソース]:",sr.serializeToString(a));
})();
<a href="+location.href+"..とやる奴が馬鹿なのか、HTMLが駄目なのか、良くわからなくなってくるほどこの手のスクリプトは多い。
11月に入って再びゴキブリが出始めた。今回コンバットではなく、フマキラーホウ酸ダンゴ18個入りが298円だったのでそちらを使用。コンバットは6個入りで600円近くした。便宜上リマインダとして「コンバット」という名称を使っておく。仕掛けたのは以下の9か所。
コンバットのように粘着テープが付いていなかったが、古いコンバットの粘着テープがまだ使えたので、最大限再利用した。やっぱり値段が高いだけあって使い勝手はコンバットの方が上。
残り9個はジップロックで封をしてゴキジェットの隣に保管しておくこととする。
下影陰線引け。一時80.63円と4日以来の81円割れとなった。しかし雲の上限が支えとなり、81円台に戻して引けている。雲の上限は本日80.85円へとやや上昇。引き続き雲のサポートが機能するか注目される。
ただ、さらに84円前半まで反発幅を広げられないと、現在辛うじて基準線82.41円を上回っている転換線は、25日以降に基準線を下回ってくる。売りサインが点灯することになり、ローソク足も雲の中で重い動きになると考えられる。
豪ドル/円の話。一目均衡表はややこしいから好きじゃない。ややこしいからというより、そういう日本人的なややこしいものを基準に取引をする人が世界に多いとは思えないから。皆が考えていることを想像して張るのが基本だと思っている。ドル円なんかでは有効かもしれんけど。
ところでこの日記だが、仕事ではやむなく使うものの今プログラミングというやつに全く興味がないので、当分システムをどうこうする気にはならない。ウェブのコミュニケーションにも限りなく関心がない。かろうじて残っているのは、「どうせ書くなら、そしてそれが公開しても問題ないなら、公開しておこう」程度の動機。それだけだ全く。テーマも何もない。ここ数日の日記も、分からない人には何の事だか分からないだろう。だがもう気にしないよ。何について書くかなんて吟味するのも億劫だ。
分散させるうまみはないが一応転送量の問題はあるから、春、夏、秋、冬と季節単位に分割することにしよう。来年の1月1日から開始。季節ごとにスタイルシートを変えたりするのは楽しそうだしな。
というか、公開すべきものとすべきでないものを分けるのが面倒くさい。