3

日中はフロントエンドの Web 開発者ですが、オフの時間は C、Objective-C、Python などの他の言語に手を出しています。最初に Web 開発を始めたとき、Web アプリケーションのアイデアはまだ始まったばかりでした。

それ以来、SproutIt の SproutCore と 280 North の Cappuccino (+Objective-J) という 2 つの素晴らしいフレームワークが登場しました。SproutCore は、Apple の MobileMe アプリケーションと 280 North がリリースした 280 Slides に使用されています。これらのアプリケーションはどちらも素晴らしく、Web で何が可能かを証明しています。そのため、勢いが変化しています。デスクトップ アプリケーションのように見え、動作する Web アプリケーション。

私の質問は次のとおりです。Web ベースのアプリケーションは、マークアップ (コンテンツ)、プレゼンテーション (デザイン)、動作 (機能) の分離という Web 標準に従うべきですか、それとも従わないべきですか?

ソースコードを見ていないので、SproutCore についてはわかりませんが、280slides.com にアクセスして JavaScript をオフにすると、基本的にすべてが消えてしまうことはわかっています。意味のない言葉がいくつか残っています。

はっきりさせておきますが、280 Slides などの Web ベースのアプリケーションは JavaScript をオンにすることを意図しており、JavaScript なしで機能することを意図していないことを理解していますが、私の日常の仕事では、クリーンなマークアップを作成し、コンテンツ、プレゼンテーション、および動作を分離して、私たちのサイトとアプリケーションは、できるだけ多くの人が使用できます。

4

6 に答える 6

5

これまでに回答した他の人は、あなたが何について話しているのかわからないようです。

私と同じように、Web アプリケーションを可能な限りアクセシブルにするために頭を悩ませてきました。つまり、スクリプトやスタイルシートなしで機能する必要があります。JavaScript と CSS は、エクスペリエンスを向上させる目的でのみ使用してください。それらは必須ではありません。

SproutCoreとCappuccinoは、ユーザーが JavaScript と CSS の両方を有効にする必要があるフロントエンド開発用のフレームワークです。あなたの質問は、これを今日の教義とどのように調和させるかについてです。

残念ながら、明確な答えはありません。SproutCore と Cappuccino (およびおそらく他のもの) が Web ブラウザー内で可能なことの限界をテストしているという事実が気に入っています。また、テクノロジーの限界を考えると、ウェブ上で提供される情報やサービスは、できるだけ多くの人が利用できるべきだと固く信じています。

ソリューションへのアプローチ方法は、ユーザーベースに関する深い知識に基づいている必要があります。iPhone アプリで作業している場合、従来の Web アクセシビリティについて心配する必要はありません。エクスペリエンスは非常に視覚的なものだからです。一般ユーザー向けの Web アプリケーションを構築している場合、これらの新しいフレームワークはおそらく適切な選択ではありません (情報やサービスへの可能な限り幅広いアクセスを重視する場合)。

時間が経つにつれて、スクリーン リーダー ソフトウェアは JavaScript を多用するインターフェイスの解釈を改善する可能性が高いため、おそらくこの問題は解消されるでしょう。つまり、別の何かがその場所で「芽を出す」可能性が高いということです。

于 2009-03-06T21:38:27.183 に答える
2

JavascriptはWeb 標準です。たとえば、以前は (そして今でも頻繁に) リッチ Web アプリケーションに使用されていた Flash よりも確実にそうです。この点で、SproutCore と Cappuccino は私の著書の大きな改善点です。

ここでの問題は、アクセシビリティがいかに重要かということです。アンドリューが言ったように、それは主にユーザーの知識に基づく個人的な決定です。一部のアプリでは、アクセシビリティはあまり意味がありません。280 Slides はその良い例です。これは主に視覚的な動作に関するグラフィック デザイン アプリです。平文に劣化するのはあまり意味がありません。(少なくとも、280 Slides が行うことを実現するためのテキストベースのアプリは、実際にはまったく別のものになるでしょう。)

于 2009-03-06T22:36:55.187 に答える
1

はい。最初は難しいかもしれませんが、コードベースが成熟すると、これらの厳格な基準に従っていることに感謝するでしょう。

編集:追加の利点は、CSS プロファイルなどを介した多くの Web ベースのプラットフォームへの移植性です。

于 2009-03-06T19:49:13.093 に答える
1

MVC モデルは、Web ベースのアプリケーションと同じくらい簡単にデスクトップ アプリケーションに適用できます。この 2 つを区別する理由はあまりないと思います。特に、Web アプリケーションの場合はその境界線がよりぼやけているためです。

これらの特定のフレームワークについては知りませんが、最近の多くの Web フレームワークは、ASP MVC、CakePHP、Ruby on Rails など、MVC モデルを中心に構成されています。

于 2009-03-06T19:51:55.957 に答える
0

できるだけ分けて、最終的に支払います。物事が複雑で毛むくじゃらになるとき:)

于 2009-03-06T19:54:13.283 に答える
-1

私は彼らがすべきだと思います。このタイプのMVC 設計に従うと、変更をより簡単に実装できるようになり、関心が適切に分離され、プロジェクトの初心者にとって一般的に理解しやすくなります。

于 2009-03-06T19:50:41.450 に答える