kufu · daxelbook · Apr 27, 2023 · May 30, 2023 · Jun 2, 2023 · May 30, 2023
@@ -15,18 +15,18 @@
     "format": "eslint --fix --ext 'src/**/*.{ts,astro}'"
   },
   "dependencies": {
-    "@astrojs/vercel": "^3.2.5",
-    "astro": "^2.1.9",
+    "@astrojs/vercel": "^3.4.1",
+    "astro": "^2.5.6",
     "astro-compress": "^1.1.46"
   },
   "devDependencies": {
     "@typescript-eslint/eslint-plugin": "^5.59.8",
     "@typescript-eslint/parser": "^5.59.8",
     "eslint": "^8.41.0",
-    "eslint-plugin-astro": "^0.27.0",
+    "eslint-plugin-astro": "^0.27.1",
     "npm-run-all": "^4.1.5",
     "prettier": "^2.8.8",
     "prettier-config-smarthr": "^1.0.0",
-    "prettier-plugin-astro": "^0.9.0"
+    "prettier-plugin-astro": "^0.10.0"
   }
 }
@@ -5,4 +5,38 @@ description:
 tag: word,デザインツール
 ---
 
-この記事は準備中です。
+Fireworksとは、ウェブサイトやモバイルアプリケーションなどのデジタルプロダクトの画面設計やプロトタイピングを行なうためのビットマップとベクターのハイブリッド型グラフィックスエディタである。正式名称はAdobe Fireworksで、Adobeが買収する前はMacromedia Fireworksという名称だった。
+
+Fireworksの最たる特徴として、ラスター形式のデータとベクター形式の画像を同時に扱うことができる点が上げられる。従来のデザインツールではラスター形式のデータ編集はPhotoShop、ベクター形式のデータ編集はIllustrator..など別々にツールを使い、組み合わせる必要があったが、Fireworksではその両方のデータを直接扱えることが革新的だった。
+
+## 代表的な機能
+
+### デザインデータ形式
+Fireworksでは、イラストレーションなどの画像や画面デザインなどのUIを、Fireworksの独自形式である`.fw.png`形式で保存できる。ユニークな点としてFireworksで作成したPNGデータはそのまま画像ファイルとして使うことも可能で、編集性を保ったままWebページに埋め込むこともできる。
+
+### 共通要素のシンボル化
+Fireworksでは、「シンボル」と呼ばれる再利用可能な要素を設定し、それを複数のページや同一ページに配置できる。マスターデータシンボルが編集されると、そのシンボルのすべてのインスタンスに変更が反映される。Figmaでいうところのコンポーネントに近い機能である。
+
+### プロトタイピング
+
+当時単独でプロトタイピング機能を提供しているツールはほとんどなかったが、Fireworksは「インタラクティブPDF」というフォーマットを使って簡易なプロトタイプとして出力できる機能を提供していた。これはFireworks上でホットスポット機能よるクリッカブルなエリア作成と、移動先となるページを指定できることで実現していた。
+
+## バグの多さ
+
+Fireworksで忘れられないのは、バグの多さである。特にFireworks CS4の頃は、バグが多すぎて使い物にならないという声が多かった。Adobeが買収した後もバグの修正は進んでいたが、最後までその印象を払拭できなかった。
+
+それでもFireworksは、デザインツールとしてのコンセプトが優れていたため、多くのデザイナーに愛された。
+
+## Fireworksの終わり
+
+Adobeは2013年にFireworksの開発とアップデートを停止した。その理由については、Adobeが他のソフトウェア（例えばPhotoShop、Illustrator）にリソースを集中することを決定したからと考えられる。
+
+当時この発表に多くのFireworksユーザーが失望した。AdobeはPhotoShopやIllustratorをFireworksの代替としてしばらく推奨していたが、そもそものコンセプトとしてスクリーンデバイス向けに設計されていないため、これらツールは完全な代替にはなり得なかった。
+
+完全な後継ツールとしてはAdobeXD、Sketchや:[Figma]:などの登場を待つことになった。これらのツールはFireworksのコンセプトを引き継ぎ、さらに進化させたものと言える。
+
+Fireworksは今もこれらのツールに魂として受け継がれている。
+
+
+## 参考文献
+- [Adobe Fireworks - Wikipedia](https://ja.wikipedia.org/wiki/Adobe_Fireworks)
@@ -0,0 +1,112 @@
+---
+layout: ../../../layouts/wiki/ArticleLayout.astro
+title: 動名詞ではなく動詞で考えるのか
+description:
+tag: column, UXライティング
+---
+
+新しい機能を追加する際に、オブジェクト（以下名詞）とそれに紐づくアクション（以下動詞）を導き出すが、それらを命名する際の適切なガイドラインを考えたいです。ここでは名詞と動詞を繋ぐ格助詞の使い方について考察します。
+
+## 前までの用法
+今まで、ソフトウェアのラベルで格助詞の「の」と「を」が混用されているところを多く見てきました。例えば
+
+- 「CSVファイル**の**作成」
+- 「CSVファイル**を**作成」
+- 「依頼**の**送信」
+- 「依頼**を**送信」
+
+「の」を使うことで名詞で終わり、「を」を使うことで動詞で終わります。このように格助詞の使い方にブレが生じてしまうと、UIテキストに細かく差が出てきてしまうので、どのような形がベストなのか考察していきたいです。
+
+## 助詞とは何なのか
+まず助詞の概念を改めて認識します。
+
+> 助詞は、言葉に意味を肉付けする語です。  
+> //中略  
+> 言葉と言葉をつなぎ、微妙な意味を肉付けする重要な役割を果たすのが助詞です。  
+> 引用: https://prowriters.jp/grammar/postpositional_particle#c52202ec3836779586d8493ce1217769  
+
+次は格助詞です。
+
+> 格助詞は、おもに体言のうしろについて、その体言が、文中の他の言葉に対してどのような関係かを示す働きをする助詞です。  
+> 引用: https://upwrite.jp/grammar/postpositional_particle
+
+ユーザーに正しい情報の関係性を認識させるためには、この格助詞を適切に使う/ある一定のルールの中で使うことが重要なのでしょうか。
+
+### 格助詞「を」の用法
+
+>「を」は大きく分けて【対象】【起点】【経過域】の3つの用法があります。  
+
+> 【対象】の用法  
+> 【変化の対象】  
+> 本を棚に戻した。  
+> 
+> 【動作の対象】  
+> 文法を勉強した。  
+>  
+>【心的活動の対象】  
+> 悲しい過去を思い出した。  
+>  
+> 【起点】の用法
+> 【移動の起点】  
+> 最後に学校を出た。  
+>  
+> 【経過域】の用法  
+> 【空間的な経過域】  
+> 道の真ん中を通った。  
+> 
+> 【時間的な経過域】
+> ゴールデンウィークを海外で過ごした。 
+>
+> 引用: https://japanese-language-education.com/bunpo2/  
+
+
+色々と細かい違いはありますが一貫しているのは「（動作の対象）を（動作）」という構文でしょうか。では「の」の用法はどうでしょうか。
+
+> 部分の主語  
+> 妹 の 描かいた絵を見る。※  
+> 
+> 話 の 好きな人だった。※  
+>
+> 連体修飾語	学校 の 友達と話す。  
+> 並立へいりつの関係	行く の 行かない の と 迷う。  
+> 体言の代用だいよう	本を読む の が好きだ。  
+>
+> 引用: https://www.kokugobunpou.com/%E5%8A%A9%E8%A9%9E/%E4%B8%BB%E3%81%AA%E6%A0%BC%E5%8A%A9%E8%A9%9E%E3%81%AE%E7%94%A8%E6%B3%95/
+
+こちらも色々ありますがこのケースでは修飾語的な使い方になりそうです。
+
+## 「の」なの？「を」なの？
+では前提を踏まえつつ結局「の」の方が良いのか、それとも「を」が良いのかを考察します。
+先にを結論を言うと「を」が妥当そうです。以下にいくつかの理由を書きます。
+
+
+### 1. ユーザーのニーズはアクションに始まりアクションで終わる
+UIを設計する際に初期で重要なのはユーザーストーリーやユースケースの選定です。あるドメインの一連の作業をソフトウェアに置き換えた時にユーザーはどんなゴールを達成したいのかを細かく分解すると複数のアクションが生まれると思います。ここで重要なのがオブジェクト起点の設計かタスク起点の設計かに関わらず、ユーザーは最終的にあるアクションでゴールを達成するということです。そうなれば「の」を使い動名詞にするより「を」を使い動詞に焦点を当てたほうがソフトウェアを使うプロセスにおいては適切な気がしています。
+
+### 2. 動名詞には限界がありそう
+もともとこの記事は[「を」と「の」の使い分け](https://bit.ly/32CJfkY)から着想を得ました。そして色々を思考を巡らせると、どうやら動名詞には限界がありそうなことが見えてきます。例えば記事の中では**Finderを見えないようにしたい**というユースケースがあってアクションを考える時に、そのアクションを「の」を使って命名すると
+- Finderの隠し
+- Finderの隠蔽
+- Finderの非表示
+
+どれもローカライゼーションが失敗しているよう感じになりますね。最後の「Finderの非表示」はまだいいですが筆者も書いている通り少し違和感はありますね。要するに格助詞の「を」を「の」に全て置き換えるには限界がありそうです。一方で「を」であれば動詞を直接くっつけるだけなので限界はありません。
+
+### 3. 他の大きいアプリケーションもそうしている
+先述の記事にも書かれていますがPagesやGoogle Chrome、またAmazonやTwitterも「（名詞）を（動詞）」の形をとっています。記事の中ではMicrosoft Wordだけ「（動詞）の（名詞）」という形をとっています。不思議ですね。まぁ他のアプリケーションもそうだしそれに則ろう的な考えでもいいかなと思います。
+
+ですが、ここで多くの利用者がいるサービスの例をみると色々がパターンが見えてきます。FacebookやGSuiteなどを見ているとアクションへの導線の見出しやタイトルは「の」を使い、最終的なアクションを発火するボタンには「を」を使っているみたいです。
+
+|  Gmail  |  Facebook  |
+| ---- | ---- |
+|![Gmailのボタンの例。「アカウントを作成する」というラベルが記載されている。](https://s3-ap-northeast-1.amazonaws.com/kufutools-codimd/uploads/upload_61bf910468bd06884cad2c6121acd8b6.png)|![Facebookのボタン群の例。「ニュースフィードをカスタマイズ」というラベルが記載されている。](https://s3-ap-northeast-1.amazonaws.com/kufutools-codimd/uploads/upload_a29cf1ae8e14e26fb341c78a2d89287a.png)|
+|![Googleのアカウントを作成するページの一部。「Googleアカウントの作成」という見出しが記載されている](https://s3-ap-northeast-1.amazonaws.com/kufutools-codimd/uploads/upload_741c06176db76aba149cacef90f6668f.png)|![Facebookのニュースフィードの設定のページに遷移するリンク。「ニュースフィードの設定」というラベルが記載されている。](https://s3-ap-northeast-1.amazonaws.com/kufutools-codimd/uploads/upload_16852151966fd53461795ca66bc9f7c7.png)|
+
+
+確かにアクションを実際に起こさないリンクが「を」を使っているのは確かに違和感ありますね。なので最終的な結論は以下のようになります。
+
+1. 最終的なアクションへの導線の見出しは「の」を使ったほうが良さそう。
+2. 最終的なアクションのボタンやリンクは「を」を使ったほうが良さそう。
+3. 但し「の」を使う場合には「を」との整合性を考えた時に表現の限界はあるかもしれない。
+
+## あとがき
+こちらの記事は2020年に社内向けのドキュメントとして公開しました。まだ当時はSmartHR Design Systemも無かったときなのでこの記事の影響はいくらかありましたが、今ではUXWにおける考えもまとまっていますし、実際の利用者に与える影響は微々たるものだと考えます。あくまで思考のきっかけになるものとして参考にしていただければ幸いです。
@@ -1,8 +1,12 @@
 ---
 layout: ../../../layouts/wiki/ArticleLayout.astro
 title: スクラム
-description:
+description: アジャイル開発の一種で、チームが迅速かつ柔軟に開発を進めるためのフレームワーク。
 tag: word,開発手法
 ---
 
-この記事は準備中です。
+スクラムは、:[アジャイル]:開発の一種で、チームが迅速かつ柔軟に開発を進めるためのフレームワークです。
+詳細な考え方や具体的な手法については、最新のスクラムガイドを参考にしてください。
+
+- スクラムガイド https://scrumguides.org
+- スクラムガイド 2020（日本語版） https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
@@ -5,4 +5,9 @@ description:
 tag: word,ツール
 ---
 
-この記事は準備中です。
+音声ブラウザは、音声によるインタラクションを通じてウェブコンテンツにアクセスするためのブラウザのことを指す。  
+音声ブラウザの詳しい概要は[音声ブラウザ｜用語集｜エー イレブン ワイ［WebA11y.jp］](https://weba11y.jp/glossary/a/%E9%9F%B3%E5%A3%B0%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6/)を参照すること。
+
+## 代表的な音声ブラウザ
+
+- [音声ブラウザ NetReader Neo](https://www.aok-net.com/products/netreaderneo.html)