You are an expert tailwind developer. A user will provide you with a
low-fidelity wireframe of an application and you will return
a single html file that uses tailwind to create the website.
They may also provide you with the html of a previous design that they want you to iterate from.
Carry out any changes they request from you.
In the wireframe, the previous design's html will appear as a white rectangle.
Use creative license to make the application more fleshed out.
if you need to insert an image, use a colored fill rectangle as a placeholder. Respond only with the html file.
スクリーンリーダーで確認したところ、ボタンを押しても何も読み上げられない。これは問題だ。「Checkbox B moved to the left」のように伝える必要がある
何の案内もなければ、ユーザーはボタンを押したとき実際に何かが起きたのか分からない。テストページ: https://output.jsbin.com/jixoqur/quiet
1件のコメント
Hacker News の意見
tldraw の Steve です。これはセキュリティパターンがひどいおもちゃプロジェクトなので申し訳ない。ローカルで実行したりソースを見たりするならここにあります: https://github.com/tldraw/draw-a-ui
ほかの例は https://twitter.com/tldraw で見られます。tldraw やこのプロジェクトについての質問には答えられます。誰かの仕事を奪うようなものではありませんが、遊ぶには本当に楽しく、より複雑な例はこちらにあります: https://twitter.com/tldraw/status/1725083976392437894
MIT ライセンスで公開したばかりのライセンスサーバーもある。Elixir で書かれていて https://go.robocoder.app を動かしている。設定で助けが必要なら連絡してくれていい: https://github.com/emcmanus/robocoder-server/
答えは GitHub README にあった。「自分の API キーを使うには usage tier 1 へのアクセス権が必要で、現在の tier と上げ方は OpenAI の設定で確認せよ」という内容だった
リポジトリにあるシステムプロンプトはこうなっている:
ここで「creative license」がなぜ言及されているのかはよくわからない。各生成ごとのユーザープロンプトは次のようになっている:
https://github.com/tldraw/draw-a-ui/blob/8a889bf36afc06fbb0c...
通常の tldraw キャンバスをスクリーンショットに撮って、このプロンプトと一緒に API に渡せば、「非公開で」動かすにも十分単純そうだ
Facebook の面接質問に出てきたモックを入れてみた。チェックボックスのリストが2つと、チェックされた項目を相互に移動するボタンが2つあるものだったが、ちゃんとできていた: https://gist.github.com/milesrichardson/2a2f77d4bfb19c3b28dc...
toList.appendChild(item.closest('li'));が項目を移動させるとはまったく知らなかった。毎日ひとつ学ぶものだ何の案内もなければ、ユーザーはボタンを押したとき実際に何かが起きたのか分からない。テストページ: https://output.jsbin.com/jixoqur/quiet
こうした最新デモは、最近の機械学習/AIの進歩がどれほど印象的かを示す一方で、世界中の何百万もの開発者が、どれほど反復的で創造性の低い作業を繰り返し再実装しているかも示している
たいていのUI画面は1〜2段落で正確に説明できるので、比較的小さな埋め込みベクトルの中にかなり詳細に表現できても不思議ではない
実務でAIを本格的に使ったことのない非技術職は特に影響を受けやすい。現場で使っている人たちは、たいていもっと微妙な見方をしている。非常に便利だがミスも多く、プロダクション水準の結果を得るには細かく手を入れる必要がある。AI楽観派としても、価値は本物で、印象的なデモは私たちが向かう方向を示していると思うが、平均的な結果が膨らんだ期待に追いつくまでには時間がかかる
このデモでは、文字どおりCSSプロパティ2つを調整するスライダー2つなので、UI仕様に含まれる情報量は多くない。適切なUI仕様言語があれば、3行のコードで済んだはず。難しさは、Web UIのボイラープレートを管理しなければならないところから来ている
奇妙なのは、HNでは従来型のノーコードプラットフォームについて話すとき、スケーラビリティや保守性の限界をすぐ見抜くのに、AIが付くと突然そうした問題が解決され、ブラックボックスが吐き出すスパゲッティを心配しなくてよいかのようになる点
本当に欲しかったのは、機能と表現を分離することだった。偶然にも、1996年の純粋なHTMLのWebがまさにそれだった。何かが想像を超えるほど愚かな形でひどく間違い、誰も改善しなかった。代わりに残ったのは、影や内側のflexboxのようなものだけ
ホワイトカラー業務のかなりの部分は同じことの繰り返しであり、別々の会社で本質的に同じ作業を別の人たちが繰り返していることが多い
これはUIデザイナー、あるいはプロダクトオーナーを賢く有能に見せるためのツールに見える。だが本当の仕事は、今までどおりプログラマーに回ってくるだろう
UIデザイナーは「デモ」を渡せるかもしれないが、この基本機能がアプリの残りの部分とどうつながるのか？ つながらないだろう
GPT以前から、ごく初期のプロトタイプやモックアップは、内部機能の完成度に比例して見た目の完成度も低く見えるようにすべきだという主張があった。きれいで、見た目には「動いている」UI専用プロトタイプは、明確に説明しても非現実的な期待を生み、プロトタイプがそのままプロダクションになる proto-duction の可能性を高める
ある役員が承認したFigmaデザインの制約のせいで、ひどいシステム設計がエンジニアに押し付けられたプロジェクトを何度も見てきた。もちろん、そういう組織にはもっと大きな問題もあるが、手軽な高忠実度モックはワイヤーフレームよりもこうした問題を悪化させた
もっと上手にやらせたいなら、"it's very important for my career" も付ければいい
箱を拡大して回転させるデモを作っている開発者たちは、もう職を失いそうだ
顧客と、私たちのソフトウェアを顧客のソフトウェアに統合する方法を話し合っていたところ、顧客がメインフォームのスクリーンショットを送ってくれた
そのスクリーンショットをChatGPTに入れて、「こんな感じのReactフォームをBootstrapで作って」と頼んだ。いくつか調整したあと自分のソフトウェアを接続し、数時間後には、システムがこんなに早く統合された概念実証を見て顧客が驚いていた。Web開発中にCSSレイアウトの問題があると、スクリーンショットをChatGPTにアップロードして解決方法を聞くことがあるが、ツイートのデモもかなり似て見える
派手なユースケースには優れているが、よくある基本的な作業には過剰なフレームワークが次々に出てきた。例外もたまにはあったが、ほとんどのWeb開発者はそういうものを好まない。履歴書で見栄えがするわけでもないし、正直、キャリアを通じてWebフォームだけを作りたい人がどこにいるだろうか
結局、亀の上に亀が乗っているようなものだ :+)
コーディングでは、ChatGPTよりもコマンドラインパイプやBashスクリプトでデータを素早く加工する用途に多く使っていた。コマンド出力を渡して、望む整形、集計、ソート、抽出用のBashを頼むと、デバッグや仮説検証のように本来ならやらなかったことも簡単になる。手作業でもできるが遅いし、オプションや引数を覚えるには検索やmanページが必要になる。コードには主にGH Copilotを使っている
懐疑論者と呼んでもらって構わないが、ノーコードソリューションの未来は信じていない。小さなデバイスの解像度でボタンを整列させる必要があり、他言語でも見栄えよく余白を残す必要があり、ほかの要件も次々に出てくる。
せいぜい、より抽象化された言語でアプリをより速く作れるようにする程度だろう。これは三目並べのような極めて基本的でありふれたものには通用するが、独創的な作業には向かない。
技術を少しだけ知っている数十人がスケッチを描き、「実際に作って」と押して機能を追加するところを想像すればいい。それぞれが数百行のコードを生成する。一日の終わりには誰かがその出力物を理解しなければならないが、出力は非決定的なので、われわれに残るのはそれだけだ。
同時に、音程を合わせて歌う方法を学べなかった、あるいは学びたくなかった新しい人たちが、はるかに少ない労力でまったく新しい音楽ジャンルや大衆向けポップを作ることになる。職人たちも一部のワークフローを強化し、完成度を高め、スピードを上げるために、まれに使うだろう。
CanvaやFigmaのようなツールは、こうした機能を積極的に取り入れて、高忠実度のワイヤーフレームやデモを大きく改善しそうだ。
SquarespaceやWixなどはすでに市場の下位層を獲得しており、そうでなければインドへのアウトソーシングが取っていたはずだ。
これは同じ概念の自然な進化だ。ウェブサイトビルダーのプロダクトマネージャーなら、こうしたAIビルダー統合にすぐ飛びつくだろう。ほとんど定義されていない複雑なビジネス作業には絶対に通用しないが、写真ビジネス向けの料金計算機くらいならうまく作れるはずだ。
ビジネスプロセスのワークフローソフトウェアはかなり人気がある。人々がドラッグ＆ドロップやインタラクティブなウィジェットエディターで似たようなことをするアプリは多く、複雑なフォーム、親子関係、状態遷移も扱える。GPT Visionのようなものを使えば、ウィジェットのドラッグ＆ドロップを飛ばして、より自由な描画ツールや手描きスケッチを使える。今日もっとも人気のある例はおそらくNotionで、ずっと以前からさらに複雑な例もあった。
もう年を取った気分だ。数十年前にもVBやDelphiで、ほとんど同じ速度でこれができたように思う。ただし、ラベル名からツールが推論する代わりに、結果はもう少し決定的だった。
われわれはすでにこういうものを持っていたのに、すべてをブラウザに押し込み、生成AIモデルの膨大な計算を使わなくても実現できたという事実を忘れてしまった。雲に向かって怒鳴る老人になった気分だ。
もちろんDreamweaverのコードは醜くて使いものにならないレベルだったし、AI生成コードは時にはそれほど悪くない。それでも、すでに今日の地点にかなり近いところまで来ていたように思う。
VBは非常に強い思想を持ったツールで、ネイティブなWindows風UIだけを作っていた。デザイナーが持ってきた任意のモックアップや、完全にカスタムされたルック＆フィールをピクセル単位でVB上に再現することはなかった。今日のほとんどの製品GUIはブランドの一部だ。良くも悪くも、どの会社も独自のルック＆フィールとUIの挙動を望んでいる。だから作るツールははるかに複雑でなければならない。ブラウザ上でもVBを再現できるし、実際に似たものを作った人も多いが、企業は退屈で一般的なUIを望まないため、製品開発ではあまり使われない。
基本的には、図のスクリーンショットをGPT-4に送り、「これを実装して」と頼む方式で動作する。
その10年後には、当時比較的新しかったJava向けに同じことを提供していたVisix Vibeというものが1〜2年ほど出回っていた。数年ごとに、おおよそ4〜5年あるいは10年に一度、誰かがあらゆる複雑さを消し去りたがる。だが結局、彼らはOSを作ることになる。
しかも実際にきちんと動作し、ツールキットの他の部分と期待どおりに相互作用し、国際化とアクセシビリティも一貫してうまく機能する。HTMLが標準提供だけではるかに多くのことをできない理由はなく、そうすれば毎年膨大な開発者の時間とユーザーの苛立ちを減らせる。だが、そうしていないだけだ。