アカウント名:
パスワード:
新UI上に旧UIへの切替機能を持たせて共存させるのは難しいんでしょうか？
全然分野が違いますが、Aruba製品のWebUIは新UIがデフォルトで旧UIへの切替機能がついています。
コストは別としてインターロックを追加する等がややこしいとかかな？識者の方にご教示頂ければ幸いです。
その考え方はソフトウェアの設計・保守の問題が大きいと思う。新UIで刷新され不要となった内部ロジックを残しておかなけらばならないとか、新旧共存するために内部ロジックが複雑になるとか、果ては新UIの一部表示方法の評価が高いからそれを旧UIに反映して欲しいとかわけわからん事態になる。
妥協ラインとしては、UI切り替え機能を次期バージョンとして新たに設計して、中核レイヤーの上にUIのレイヤーを作り、切り換えはUIのレイヤー部分のみで完結するようにし、旧UI「風」の表示に切り替えられるようにするというもの。これは実質機能の刷新は行われていて、ソフトウェアの健全性は保たれる。これでもユーザーにとって機能の増減は起こるが、外見が維持される部分が多いので差分を認識しやすいし、ユーザーと開発のディスコミュニケーションを抑えられるかもしれない。
が、それもコストは安くない。
UI部分に係る部分ってシンプルさに欠ける作りが避けられない作りなりやすい→保守すごく手間
なのに安く見られるのが一番問題だと思いますけどね〜#絵を描いてるんじゃないんだぞと
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
UIの共存って難しいんでしょうか？ (スコア:0)
新UI上に旧UIへの切替機能を持たせて共存させるのは難しいんでしょうか？
全然分野が違いますが、
Aruba製品のWebUIは新UIがデフォルトで旧UIへの切替機能がついています。
コストは別としてインターロックを追加する等がややこしいとかかな？
識者の方にご教示頂ければ幸いです。
Re:UIの共存って難しいんでしょうか？ (スコア:1)
その考え方はソフトウェアの設計・保守の問題が大きいと思う。
新UIで刷新され不要となった内部ロジックを残しておかなけらばならないとか、
新旧共存するために内部ロジックが複雑になるとか、
果ては新UIの一部表示方法の評価が高いからそれを旧UIに反映して欲しいとかわけわからん事態になる。
妥協ラインとしては、UI切り替え機能を次期バージョンとして新たに設計して、
中核レイヤーの上にUIのレイヤーを作り、切り換えはUIのレイヤー部分のみで完結するようにし、
旧UI「風」の表示に切り替えられるようにするというもの。
これは実質機能の刷新は行われていて、ソフトウェアの健全性は保たれる。
これでもユーザーにとって機能の増減は起こるが、外見が維持される部分が多いので差分を認識しやすいし、
ユーザーと開発のディスコミュニケーションを抑えられるかもしれない。
が、それもコストは安くない。
Re: (スコア:0)
UI部分に係る部分ってシンプルさに欠ける作りが避けられない作りなりやすい→保守すごく手間
なのに安く見られるのが一番問題だと思いますけどね〜
#絵を描いてるんじゃないんだぞと