  |
はてなキーワード: UXとは
出品した商品が落札され、落札者が代金を支払うとヤフオクから出品者のメールアドレスに「支払い完了」の連絡が来る。それには「商品を発送し落札者に連絡してください。」と書かれている。
しかし、実際の支払い状態を見ると「ヤフー審査中」になってて取引ナビでは
「ヤフー審査中」「支払期限切れ」「キャンセル」の場合は、商品の発送をお待ちください。
という記載があり、まだ発送すべきではない状況だった。
この支払い状態は取引ナビから見ることができない。Yahoo!かんたん決済の「売上金管理」リンクから状態を確認しなければならないのである。
メールでは「発送しろ」、取引ナビ(と売上金管理)では「待て」と矛盾したことになっている。
発送すべきではない状況にもかかわらず、取引ナビでは発送手続きができるような画面が表示される。
Yahoo!かんたん決済の売上金管理で、支払い状況が「受取連絡待ち」であることを確認してから、配送に必要な二次元コードを発行してください。
と表示するのではなく、発送手続きをできないようにするべきである。
審査待ちなのに発送してしまう事故が既に多発していると思う。これでトラブルが起きた時はどうするつもりだろうか？
この使い勝手が悪い理由はYahoo!かんたん決済との連携が全然とれてないから、と簡単に思いつくが、同じ自社ブランドなんだしそれぐらい連携しようよ((※Yahoo! JAPANがどういう組織か全く知らない人間なので、事情を知らずに単純に言ってます))。
20年近く昔からやっててもこの辺のUXが洗練されてないって、サービスとしてどうなんだと思う。
自分はまだ出品数が少ないからいいけど、多数出品している人から見たらストレスしか生まれないUXだよな、これ。
https://ischool.co.jp/2017-02-03/
https://ameblo.jp/fudan-mo-kimono/entry-12408133630.html
を見てても、不満が解消されないまま今に至ってる。Yahoo! JAPANには改善という言葉がないのか？「フリマアプリ界の西成」と揶揄されてもなお勢いのあるメルカリに押される理由が何となくわかった気がする。
ブランコ以外は最近の複合遊具一台で賄えるしそっちの方が良いと思う。
ただ最近の複合遊具スゴいけど当たり外れ大きくて、子どもと色々公園巡りしているとコンパクトで簡単な作りなのに感動するほど遊べる奴（余裕で2時間くらい遊んだ）もあれば、でかくて金かかってそうなのに遊び方の幅が無くてびっくりするほどつまらない奴もある。それも新しい奴で。
注文が自治体単位なのと、遊具同士のプレヤビリティを比較した客観評価とか親からのフィードバックとかないからなんだろうけど、公園毎に違う遊具入れるとか、クソみたいなオリジナリティ加えるとかホントにいらない。（なんか変にうねうねしてると思ったら、地元のシンボルマークかたどってるとかさ）
シンプルで高評価の奴を量産してあちこちの公園におけば、量産効果もあって安くなるし、親子のUXも高まってWIN-WINだと思うんだけどなー。
Googleの検索が役に立たなくなり、ソフトのランキングも役に立たなくなった。
複雑な機能は要らないのだけど、1つの機能がわかりやすくて、組み合わせて、課題解決できればいいのにと思う。
GitHubあるじゃないかと言われそうだが、やっぱり検索が役に立たない。
棚にiTunesカードみたいなもの並べられてて、それでソフト買えたらなーと思う。
ネットの方が楽でいいじゃんとツッコまれると思うのだけど、リアルの方が探しものに便利なんだから仕方ない。
iTunesカードの形がジクソーパズルのようになっていて、ピースが合う場合は、ソフト間も接続出来ることが確認できるとか。
UI/UXと言われるけど、説明書を読まなくてもわかるのが便利なのは買った瞬間なんだよね。
以下愚痴
photoshopで作ったpsdのwebデザインを渡されて、フロントエンド担当がHTML/CSSコーディングしてるんだけどどうなのこれ？
なんでphotoshop使うの？webページ作るんでしょ？最初からHTMLで書けよ？
いや分かるよ
ラフの段階でphotoshopでササっと書いた方が客と調整しやすいもんな
でも最終的にはHTMLで出すんだから、デザイナーがHTML/CSS書いて来いよ
それをなんか知らないけど、普段使わねーphotoshop開いてルーラー出して、
「ここと、ここのボックスは10pxだからーmarginを...」
UIライブラリもフレームワークも充実してんだからphotoshopで大枠を調整したら、ササっと書けよ自分でよ
photoshopで書かれた夢いっぱいキラキラデザインの実現可能性をなんでこっちで検証しなきゃいけねーんだよボケが
今の会社含めて2社しか経験してないので、一般的かどうかは判断できないが、前職ではHTML/CSSまでデザイナーの人が書いてたぞ
(zeplinが吐く糞みたいなコードじゃなくて、ちゃんと構造化された綺麗なHTMLね)
本来はこうでしょ？
「レイヤーでマウスオーバー時の画像保存してあります」(←ふざけんなｗｗ
photoshopは画像編集ソフトであって、webページ作成ソフトじゃねーんだよ!そんな事も分かんねーのか？
webが頭についてるならwebの事ちっとは理解すべきなんじゃねーの？
「いやCSSよく分かんないんでじゃねーよ！」
Reactを書けとは言わない
でもせめて、CSSフレームワーク, flexbox, grid layoutとかは知ってるべきでしょ？
photoshopで簡単に作れてもwebページだと大変なことだってあるんだバーカ
psd渡してあとは頑張ってね！でよくwebデザイナー名乗ってるなｗ
webのこと分からないwebデザイナーなんてマジで笑いごとで済まねーぞｗ
webデザイナーならHTML/CSSを最低限知っておくべきなんじゃねーの？
んである程度分かるなら、photoshopで頑張って画像作る手間でHTMLを書けよと言いたいんだよ
いい加減目を覚ませ！！！
HTML/CSS分かんねーなら今すぐudemyで勉強してこいハゲ！
そもそも何でもかんでもwebページをポスターみたいに着飾るんじゃねーよ
ランディングページならともかく、よく使うwebアプリを着飾るんじゃねーよ、開発もしにくい、使いにくいしでまったく良いこと無い
大抵Craigslist, Hacker News くらいのデザインで十分なんだよ
それを何でもかんでもデザインの所為にして、下らん工数使って何がしたいんだか
UI/UXを考えたデザイン変更じゃなくて、糞webデザイナーのオシャレ(笑)に付き合うくらいだったら、もっと他に開発すべきことが無いか考えろ
そのwebサイトが当たらない理由をデザインの所為にするんじゃねーボケカス
正直要らない。
ひとりなら黙々とスマホをいじれば大体察してくれるが、友人らとの会話に隙あらば入ってくる空気を読まないタクシー運転手が一定数居るのは何故だ。
こないだのは酷くて、ちこちゃんの雑学披露にはじまり、身内の話をしていても隙を見つけて割り込んでくる。盛り下がるので黙って運転して欲しいが、そう伝えて機嫌を損ね、車の運転が荒くなったりしないかと怖いのでなにも言えない。
また、タクシー乗車回数の割にこういう人と遭遇する回数が多いのはタクシー運転手という職業や密閉空間という特殊性が関係しているのか。
是正のためにもUBERみたいなアプリ配車・決済と共に運転手の評価システムが早く普及して欲しい。こないだ乗った日本交通アプリは評価システムもあるし、流しを拾ってからのアプリ決済にも切り替えられたりとUXもかなり頑張ってた。
今回は、データベースを使ったWebアプリの制作を通じて、SQLの使い方を確認してみましょう。
Webブラウザー（Google Chromeなど）で動作するアプリのこと。
ウェブアプリケーション（Web application）は、インターネット（もしくはイントラネット）などのネットワークを介して使用するアプリケーションソフトウェアである。
多くの場合、これらのアプリケーションは、Webブラウザ上で動作するプログラミング言語（たとえばJavaScript）によるプログラムとWebサーバ側のプログラムが協調することによって動作し、ユーザはそれをWebブラウザ上で使用する。
Windowsパソコンを使ってたら、「XAMPP」を使ってすぐにWebアプリを試作できる。
以前の講座（その６、その９）を参考にして、XAMPPとCodeIgniterを用意しておこう。
最近のアプリの作り方は、「デザインスプリント」と呼ばれる方法が流行ってます。本やネットの情報がたくさんあるので調べてみよう。
ざっくりと、以下のような流れです。
それでは順番にやってみよう。
以前にデータベースの練習をしたとき、「後で簡単なチャット（おしゃべり）ができるWebアプリを作ってみたいと思う。」と言ったので、今回のアイデアは「チャットを作る」にしよう。
Webページを作るには、HTMLやCSSの知識が必要だ。HTMLやCSSを使ったことがなければ、本やネットの情報で勉強してみよう。
今回はCSSを使わずに、HTMLだけでシンプルなWebページを作ってみよう。（練習だから余計なもの、無駄を省きたい。）
特にこだわりがなければ、Microsoftの「Visual Studio Code」という無料のIDE（統合開発環境）を使ってみよう。
インストール方法や使い方、メニューの日本語化のやり方は、検索して調べてみよう。
「mock」フォルダの中に
テキストエディターで保存するとき、文字コードを「UTF-8」にしておく。
「index.html」ファイルをエディターやIDEで開き、以下のような内容に編集して保存します。（コピペする場合、行頭の字下げ（インデント）の全角スペースを半角スペースに置換して下さい。）
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<form>
<label>メッセージ</label>
<input type="text" name="message">
<button>投稿する</button>
</form>
<table border="1" cellpadding="5" cellspacing="0" bordercolor="#CCCCFF">
<tr>
</tr>
<tr>
<td><a href="edit.html">編集</a></td>
<td><a href="delete.html">削除</a></td>
</tr>
<tr>
</tr>
<tr>
</tr>
</table>
</body>
</html>
「edit.html」ファイルをエディターやIDEで開き、以下のような内容に編集して保存します。（コピペする場合、行頭の字下げ（インデント）の全角スペースを半角スペースに置換して下さい。）
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<p>メッセージを変更して「更新する」ボタンを押してください。</p>
<form>
<label>メッセージ</label>
<input type="text" name="message" value="Webアプリを作ってみる！">
<button>更新する</button>
</form>
<p><a href="index.html">戻る</a></p>
</body>
</html>
「delete.html」ファイルをエディターやIDEで開き、以下のような内容に編集して保存します。（コピペする場合、行頭の字下げ（インデント）の全角スペースを半角スペースに置換して下さい。）
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
<form>
<p style="background-color:lightpink">Webアプリを作ってみる！</p>
<button>削除する</button>
</form>
<p><a href="index.html">戻る</a></p>
</body>
</html>
以上でモックのWebページ（HTMLファイル）ができました。
Webブラウザーで「index.html」を開いてください。「編集」や「削除」、「戻る」をクリックして、チャットの画面を確認してください。
実務では「仕様書」という書類を大量に作る場合もありますが、時間と労力の無駄になっている場合が多々あります。（紙の仕様書はあまり使われる機会がない）
紙の仕様書（アナログ）の代わりに、モックを仕様書（デジタル）として使うと、その後の段階がスムーズになります。
どうしても紙でなければ困る場合以外は、モックをそのまま仕様書として使ってみましょう。
モック（動くハリボテ）を作るための便利なツールがいろいろあります。
ちょっと長くなったので、モックを基に機能を実装（プログラミング）するのは次回にしましょう。
anond:20181015215004 未経験からのプログラマーなんだが全然分からない
anond:20181016015826 増田式プログラマー養成講座 その１ パソコンの用意
anond:20181016164341 増田式プログラマー養成講座 その２ プログラム＝データ＋処理、プログラム言語の種類
anond:20181016180059 増田式プログラマー養成講座 その３ 構造化プログラミングの基本（順次、反復、分岐）
anond:20181016193144 増田式プログラマー養成講座 その４ 子ども向け教材「Scratch」で構造化プログラミングの練習
anond:20181017161003 増田式プログラマー養成講座 その５ オブジェクトとは何か？
anond:20181017191404 増田式プログラマー養成講座 その６ OOPの種類、PHPの準備
anond:20181019181549 増田式プログラマー養成講座 その７ OOPの仕組み（前半）
anond:20181020230044 増田式プログラマー養成講座 その８ OOPの仕組み（後半）
anond:20181022232327 増田式プログラマー養成講座 その９ MVCフレームワークを使ってみよう
anond:20181023184616 増田式プログラマー養成講座 その10 OOPの参考書
anond:20181024214133 増田式プログラマー養成講座 その11 データベースを使ってみよう
anond:20181026145516 増田式プログラマー養成講座 その12 データベースの参考書
anond:20181028152656 増田式プログラマー養成講座 その13 SQLの文法
anond:20181031014212 増田式プログラマー養成講座 その14 Webアプリの試作品を作成 ←★今ここ★
anond:20181101225335 増田式プログラマー養成講座 その15 Webアプリの完成見本
：
実を言うと、一般人はプログラミング以前に計算も理解できないんだけど、あれらはまだ大衆的な要素を内在してるから、四則演算だけを受け取ることはできる。
それまで大衆的な要素＋紙的な要素だったそろばん(計算)が、電子化へと移行する時に大衆的な要素を切り捨てたのね。より高速な計算機に進化するために。
だから、それまで大衆部分だけを受け取って喜んでた一般人は急にわからなくなりヒステリーを起こした。
だけど、コンピュータ技術者はプログラミング以前にも数学等の計算部分しか見てないから一般人が何を騒いでるのかわからない。
一般の人って、パソコンの凄い人がプログラミングになるとか勘違いしがちだけど(オタク＝パソコンの大先生論もその変奏)、全く質の違うもの。
パソコンって、アプリをひすたら立ち上げて綺麗に絵を描いたり動画を観たりするようなもの。コーディングじゃない。
日本のバカって教養がない極東の田舎者だから、コーディングを理解できない。すぐに立ち上げてって言われたときに「パソコン」を持ち上げる。怖いんだろう。自分に理解できないパソコンが。UI/UXデザインですら大多数は理解できないんだもの。あんな教科書的なものですら。
とにかくアジアって科学後進国なのね。トップの日本ですらこうなのだから。謎のスタートアップがBitCoinと人工知能を脈絡なく展示してホルホルしてるレベルだもの。
まず日本に生まれた時点で、プログラミングを理解するには圧倒的に不利。英語もできないし。こんなこと言うと、「一般人にもわかやすく説明できるのが一流ダー」みたいな恥ずかしい駄々っ子が沸いてくるけど、プログラミングって歴史上一度も大衆を相手にしてないので。
民主主義の恩恵で、一般人もセミナーでプログラミング講師のダベりを数百円で見れるようになっただけで泣いて喜ぶべき。
そしてあれは、将来の顧客とプログラマの入り口としてやってるの。1000人に1人、将来IT業界に貢献する人材がいるかもしれないと信じて。
意味不明なものが多いし何かとケチつけないと気がすまない性格だから面倒なことを一々と
直接のユーザからの意見なら多少は変でもそのユーザが必要としてるなら納得できるし、イライラすることもない
社内でそんなことこだわったところで実際には気にされないことが多いのにだ
まだデザイナーがデザインについてこうした方がUXがいいねみたいなことをいうならわかる
専門の人の意見だし
そうでもないのに何かと文句をつけてくる
CSS すらまともに使いこなせずマージンもパディングもないような酷い作りのものしか作らないのにソッチのほうが良いという
色は red, green, yellow と標準のペイントのデフォルトカラーかよというような色を指定してくる
#fcfcfc や #0a0a0a なんて使おうものなら白と黒にしろと
max-width を指定せずに画面の端から端まであるようなものがいいという
今の時代のアプリやサービスを全く見てないのか？としか言えないようなセンスだ
自社サービスなんて手を出したらこれは酷いと話題になりそうなものだ
見た目にあまりこだわれない社内用サービスしか作ってないからと言って、その他サービスをみてる人からすれば明らかに
しかもデザインに限ったことではないがまだ序盤の時点で言っておけばいいものの完成後にいまから変えるなんて難しいのが
わかりきってるようなときになってからああしろこうしろ言い出す
先に書いたようにユーザの要望ならまだ仕方ないと言えるがなぜこんな無意味なことに付き合わなければならないのか
わりと自分が完璧主義なところもあるので作るならちゃんと作ろうとしてるんだが
こういうのを相手にしないといけないせいで結局グチャグチャになってくる
色のバランスやレイアウトを考えたところで一瞬でそのバランスが無意味になるようなことになる
プログラム側だって全然関係ないものを無理やり入れ込まないといけないようなことになることも多い
疎結合だとかグローバルをつかわないとかそういう作りやすくするためのことをしていても
それが維持できないような無茶で無意味な指示が出る
根本的に変えたり対処するためのものを作るとかすればなんとかできなくはない
過去のプロジェクトでもそういうのが多いから自分で作るのくらいは扱いやすくしたいと考えていたのだが
過去に言われたものだと速度を優先だとか言って自分で作ったものよりは遅くするなと言う
しかしながら関数は使わずコピペだわforeachなどは使わずループ変数を使って地道にやるなどメンテナンスが
できる気がしないが速度においては早いと言えるものだ
当たり前のようにグローバル変数がいっぱいあるしライブラリの使用箇所はカスタマイズするための仕組みがあるのに
便利で読みやすいような書き方だと速度的にはそれに劣る
だがわざわざそんな扱いづらいし見づらいコードは書きたくない
そんなに速度にこだわるなら勝手に一人で機械語でも書いてろよって思う
どちらか取捨選択すべきものなのに両方みたせとか無理なことを言う
ちなみに便利なライブラリは基本無駄が多い遅いものだからライブラリ頼みのベンダはクソだとか
能力がないだとか言っていた
そういえば昔先輩社員と仕事したときには変に凝ったものとか必要以上に作り込んだりはしないほうがいいとか
言っていてそれなりに手抜きでさらっと一応は動くようなものを作っていた
私はそういうやり方が嫌いだったのだが今ではこういう環境に長くいた結果仕事のものにこだわって作り込んでも無駄
ということがわかってそうなったのかなと感じた
自分でもサビ残や休日に無償出勤してまでいいものにしようと努力はしていたが謎の指摘に合わせていると
愛着もなくなってきたし後は適当に済ませてしまおうかなという気持ちだ
ちゃんとした自分なりの完璧なものを作ろうとするなら仕事ではなく趣味で作ってるツールやライブラリで
やればいいかと思う
作ったもの次第でユーザが集まる自社のウェブサービスやパッケージの商品やゲームなどは作り込む方が
良いと思うが先に値段が決まって受注して作るようなものだと最低限の要望さえ満たしていればあとは
どうでもいい
むしろ不便な方が改修依頼が来て稼げる
さらには綺麗で完璧な作りで大抵の想定できる改修は１日とかからないようなものに仕上げるよりも
どこ変えればいいかや影響範囲すらわからないくらいモノのほうが実作業時間が多いのでそれだけ請求できる
先に作り込むメリットがない
ストレスが溜まってきたので発散がてら書いてみたけど疲れてるのかわりと分かりづらい文章になった
けどまぁいいか
そろそろ転職でもしたいなーと考え始めた
