WebClientのフォームエディタ
WebClientはほとんど完璧なのですが、唯一要望を出すとしたら、フォームエディタにmargin、padding、border-radius程度のスタイルは内蔵してもらえると嬉しいという点です。これさえあれば無敵です。HTML編集も外部CSSのカスタマイズも不要です。業務アプリ程度でしたらこれだけで完璧にできあがります。
業務アプリにカラフルなデザインの画面が必要になるわけではありませんので（笑
-
そういえば、ブラクラの頃はフォームエディタだけである程度、カスタマイズできましたね。思い出しました。
WebClientの場合、コントロール特性にpadding特性やmargin特性が追加されると嬉しいです。ちなみに、RIAの「位置（0,0,0,0）」特性はとても便利です。しかも、iOSやAndroidのプレビュー画面まで表示されるのを見たときは、MSEの技術力に度肝を抜かれました。
こうした特性オプションは将来的にせひ欲しいですね。Magicは日々、カスタマイズ、メンテナンスされるのが常なので、そのたびに外部のデザイナにHTMLやCSSの変更を依頼していたのではせっかくのMagicのメリットが半減してしまいます。
Magicは一匹狼のマジッシャンでも業務アプリができるぞというところが最大の武器ですのでね。
-
それと、おそらくもう一つISHIJIMAさんの要望が強いのは、オーバレイウインドウの「フォームサイズ」特性の追加ではないかと想像します。一票入りますか？（笑
-
この会議室はフォロワーがまが9人しかいませんね。9人っていうと、顔が全員思い浮かんでしまうくらいの規模ですね（笑
ほかの会議室のように、最低でも20人くらいになってくれると活性化するかもしれませんね。
-
100票受理しました！
-
ISHIJIMAさんのご質問はたぶん、オーバーレイウィンドウのことだとは思いますが、それでしたら「Web Clientアプリケーションの開発」というマニュアルに「オーバーレイウィンドウのカスタマイズ」という項目で掲載されています。しかしながら、私の想像では残念ながら既存のマジッシャンはこれを見ただけでは意味が理解できないと思います。もっと、噛み砕いて解説する必要があるかと思います。
-
ブラウザのサイズを画面の解像度に合わせて変更するということですか？
-
そうなると、ほかのタブにも影響しませんか？WebClientはブラウザアプリですから。
-
クラサバやRIAは実行ウィンドウ自体もネイティブアプリとして動いているのですが、WebClientはブラウザアプリですから同じ方法では無理があると思いますよ。
-
ちなみに、Webマージの頃はよく、JavaScriptのwindow.open()などを使って、サイズを指定した別タブで開いたりしていたのですが、最近はその方式に対して次のような危険性が報じられているようです。
https://webtan.impress.co.jp/e/2020/03/13/35510
-
う～ん、流し読みでちらっと見ただけなのですが、target="_blank"は危ないけど、window.open()ならOKっていうことですかね？ISHIJIMAさんご自身でよく読んでみてください。
-
たしかに、WebClientの場合、コントロール特性にpadding特性やmargin特性が追加されると嬉しいです。
さらに加えて、最近のフロント開発の主流になっているグリッドレイアウトの特性も追加されると良いと私は思います。
-
私も「オーバーレイウィンドウのカスタマイズ」について、もっと、噛み砕いて解説する必要があるかと思います。
マジックの人に聞いた噂では、3日間トレーニングの中で演習があるようですね。
-
そうですね、昔はフレームでチマチマやっていたのが、今はグリッドレイアウトに進化していますから、それは良いアイデアですね。おそらくそれは「特性」という形式を超えて、新しい機能として追加されていくような気がします。イスラエルのMSEはすごい会社ですから。
-
> マジックの人に聞いた噂では、3日間トレーニングの中で演習があるようですね。
それを聞いて安心しました。
マジック社の事情に詳しそうな人がフォーラムに参加してきてくれてうれしいです。
-
モバイル端末やスマホをクライアントで使うケースが増えていることを考えると
ブラウザのサイズに合わせて、意図した画面レイアウトに変更できる
「レスポンシブルWebデザイン」を画面側に施すケースも増えてきていますね。
-
> 「レスポンシブルWebデザイン」を画面側に施すケースも増えてきていますね。
ただ心配なのは、あまりWebデザイン側に焦点を移していくと、既存のマジッシャンにとっては単にプレッシャーにしかならないですから、その辺りのバランスが重要だと思います。
Magicはあくまでメンテナンス性の良い、業務アプリ開発ツールとしての進化を遂げてほしいですね。
-
おっしゃる通りだと思います。
バランスのとれた、メンテナンスも考えたツールに進化を遂げてほしいですね。賛成です。
-
一時期、Magic本体にWebオーサリングツールの機能が搭載されたMagicのバージョンがリリースされたことがあるのですが、かえって反感と負担を呼んで、自然消滅してしまったいきさつがあります。18年くらい前だったでしょうか。その轍は踏まないようにする注意も必要ですね。
-
> 有償のトレーニングコースですね・・・
ISHIJIMAさんにはうってつけのコースだと思いますよ。ぜひ参加してストレスを解消して、感想を聞かせてください（笑
-
> マジックの人に聞いた噂では、3日間トレーニングの中で演習があるようですね。
HTML、CSS、TypeScriptの部分は、控えめに控えめに解説したほうが良さそうですね。既存のマジッシャンの関心事は、あくまで既存のタスク特性のロジックがどの程度まで互換性を維持して継承できるかという1点ですから。
-
たとえば、WebClientのAPGでスクリーンモードのプログラムを作成すると、実行時の画面のレイアウトがカラムタイトル部分とカラムデータ部分とに1行分くらいの段差ができますよね。あれは欧米の文化、特にアメリカのタイプライターの文化ですから、日本人にはバグとしか見えないわけです。あれをどうやったら簡単に横1列にできるかの解説があるだけで、人気が俄然と上がりますよ（笑
-
失礼、
横1列→横1行
-
マジックの人に伝えておいてください（笑
-
もう一つです。
ISHIJIMAさんも大いに気にしておられるかと思うのですが、オーバーレイウィンドウのサイズがデフォルトでは300px x 300pxとなりますが、あれをTypeScript側で編集するのではなくて、Magicのウィンドウ特性から指示できるようになるといいです。
これは、超特急クラスのマジシャンからの要望だと思います。既存のマジッシャンは、なるべくHTMLやCSSやTypeScriptには触りたくないのです。ですが、その設定の変更は既存のマジッシャンにとって必須なんです。
-
最近、Googleのアプリを見ていて思うのですが、Gmailにしろ、Googleカレンダーにしろ、Google連絡帳にしろ、Google Keepにしろ、日進月歩ですべてがAngular化されつつありますね。びっくりするくらい、Magic WebClientで作る画面とそっくりです。
ということは、Magicでそれ相応のアプリも作れるということですから、期待が大です。それにはただ1つ、依然変わらぬ理念がありますね。Angularのことは何も知らなくてもAngularアプリが作れるという理念です。
RIAのときは、Objective-CやSwiftのことは何も知らなくてもiOSのネイティブアプリが作れましたし、Javaのことは何も知らなくてもAndroidのネイティブアプリが作れたわけです。
したがって、Angularの知識が何もなくても、HTMLの知識が何もなくても、CSSのプロパティを数個知っているだけでAngularアプリが作れますよというところがMagic WebClientにとって最大の売りになりそうです。
この先のMagicの進化が楽しみで楽しみで、ワクワクして眠れないです（笑
-
Webオーサリングツールの機能も「自由」と「不自由」の両面の特性を持ちますので、
tandaさんのおっしゃる通り、開発ツールとしてバランスのとれた進化を遂げてほしいです。
最近のフロント開発ツールの傾向では、テキストベースもあるようです。
ほかのツールベンダーに聞いたら、オーサリング機能の枠で制約するのではなく
本来Webとしての自由な表現するにはテキストの方が良いそうです。
Web Clientは、既存のマジックユーザ向けとフロントエンジニア向けに、
どちらも選べるようになってくると、より面白くなると思います。
-
例えばコントロールの「右寄せ」ですが、このような誰もが必要とする設定は、わざわざpaddingのautoやfloat: rightをCSSで記述するのではなく、従来通り、コントロール特性のプロパティで設定できるようになるとありがたいです。
上下左右の余白と、左寄せ・右寄せ・センタリングですね。最低、こういった設定はMagic側のコントロール特性で実現していただけると嬉しいですね。そうすれば、既存のマジッシャンでも無理なくWebClientの開発に臨めるはずです。
-
Webシステムの世界は流れが速いので、私はMagicが吐き出すHTMLコードを極力減らしていってほしいです。
特にHTMLの中にPaddingとかスタイルを入れるのはSEO的に必要ないとおもっております。下手なタグの構造を入れられるぐらいなら自分で組んだ方がよいです。
現に今でも邪魔なタグを消す作業からはいっていましす。弊社では社内業務アプリにもデザインにもUI/UXにも気に掛けています。
そして現在のマテリアルデザインも今後進化すると思います。
今後、過去のものになったタグを吐くぐらいなら、自分でコーディングできた方がよいとおもいます。私は業務システムもやはり見た目から入ってやっと内容の土俵にのれると思っています。
既存の動きと同じならばそれはRIAでもオンプレでもTSmagicでもよいとおもいます。
WebClientが手に入れたものは「自由」だとおもいます＾－＾。 -
WebClientが手に入れたもは「自由」かもしれませんが、Magicの場合、ご存知のように開発版もサーバ版もかなり高価な価格帯です。Webの世界で自由を求める人たちが、果たして高額な開発ツールに大金を投じるかどうかは疑問かもしれませんね。
既存のマジッシャンはMagicの開発効率の良さに惚れている人が多いと思います。したがって高額なMagicであってもそのメリットに対して代金を支払います。かりに自由がたくさん手に入ったとしても、開発効率が低下したのではまずいような気がします。
私もMagicから吐き出すHTMLコードを極力減らすことには賛成です。そして、HTMLに吐き出すのではなく、CSSのテンプレート化として簡素化するのが良いと思います。
-
そして、「見た目の良さ」というのは、現場でアプリを操作する人たちから見た、操作性の良さです。ああ、このボタンを押せば選択リストが開くのだなとか、このボタンを押せば取り消し操作ができるのだなとかの、操作性の良さですね。
これらはWebアプリであっても、クラサバであっても同じです。将来的にWebアプリでしかできないことが多くなるからこそ、マジック社もその方向性に向かっています。
現場で働くオペレータの人々たちにとっては、バックエンドは何でも良く、カラフルな画面もまったく不要です。スーパーのレジの業務アプリの画面を見るとよく分かりますね。私は女房と買い物に行くたびに、各スーパーマーケットやショッピングモールのアプリの出来栄えをのぞき込んでいます（笑
サインインしてコメントを残してください。
コメント
46件のコメント