サイボウズ Office 開発ブログ

こんにちは、岡田です。

来春リリース予定の Office 8 では、機能の豊富さや拡張性を考慮し、JavaScript のライブラリに YUI (Yahoo! User Interface Library) を採用しました。

Office 8 の開発が始まった頃 YUI のバージョンは 2.5.0 でしたが、数か月の間に 2.5.0 → 2.5.1 → 2.5.2 → 2.6.0 とバージョンアップがあり、Office 8 でもその都度ファイルを更新してきました。
YUI を更新することにより、Office 8 で正常に動作しなくなるところが出てくるといけないので毎回変更箇所のチェックを行っていますが、今回は YUI 2.6.0 の変更箇所のうち Office 8 の動作に影響があったコンポーネントをご紹介します。

Container

モーダルダイアログを表示する際、ダイアログの後ろにあるリンクやボタンを無効化する（フォーカスがあたらないようにする）処理が変更になりました。
2.5.2 までは、Tab キーでフォーカスがあたる HTML の全要素（全ての a, button, select, textarea, input 要素）に onfocus イベントハンドラをセットし、フォーカスがあたったらすぐ blur() するようになっていました。
しかし、要素数が多いと onfocus イベントハンドラをセットするだけで数秒かかってしまってダイアログがなかなか表示されない…、といったことが起こってしまいます。
2.6.0 では keydown イベントハンドラのみをセットし、Tab キーが押された時にフォーカスする要素をブラウザ任せではなく JavaScript で強制的に制御するようになりました。
これにより、要素数に関係なくモーダルダイアログを軽快に表示できるようになりました。

TreeView

ツリー上で keydown イベントが発生したらどのキーが押されたかを判別し、サブフォルダを開閉する処理が追加されました。ツリーのノードにフォーカスをあてて、矢印キーや「＋」「－」キーを押してみてください。（あまり使わないかもしれませんが…。）

今回ご紹介した2つ以外にも、Office 8 では Drag & Drop や Menu など、様々なコンポーネントを利用してリッチな UI を実現しています。パソコンの操作に慣れている方にもそうでない方にも、使っていて楽しいと思っていただけるような操作性をご提供できるよう、これからも新しいことにどんどんチャレンジしていきたいと思います。

こんにちは、梶田です。

先日行われたITPRO EXPO 2008に参加してきました。
サイボウズからも出展していまして、ブース内にて来春リリース予定のOffice8とデヂエ8を展示し、今回はそのサポートとしての参加です。

『Office8 & デヂエ8の新機能』

ITPRO EXPO 2008

このような場は、実際に使用しているユーザー様の声が直接聞ける貴重な場でもあります。しかも、Office8を実際に触っていただくのは初めてなので、開発者側からするとドキドキします。

Office7をリリースした時にもこのITPRO EXPOに参加しましたが、Office7では管理者をターゲットにした強化が中心だったため、管理者でないユーザー様の反応としましては、もっとユーザー側の機能アップが欲しいという声が多く、その想いを乗せ、Office8はエンドユーザー向けの機能強化を多く取り入れました。

まずOffice8の大きな目玉は、Officeとデヂエの連携です。なんと、Officeの中で一つのアプリのようにデヂエが使用できちゃいます。会場では、連携にちなんで「Officeとデヂエの結婚」というタイトルで巨大なウエディングケーキを青野社長がケーキカットを行うイベントを行いました。実際、Officeとデヂエを使用いただいているユーザー様に触っていただいた感想は、「今までOfficeとデヂエを別々に立ち上げて操作していたが、連携できることにより使いやすくなりそう」という声をいただきました。また、Office8では「製品内リンク」という新機能の追加により、現在表示している画面をブラウザで言うところの「お気に入り」に入れる感覚で登録できるため、よく使用するデヂエの画面を登録することで、さらに連携機能がアップされます。

office&dezie ウエディングケーキ

その他、パスワードの有効期限や桁数の制限、メール振り分け設定、スパムメール対策の機能強化、スケジュール印刷などご要望が多かった機能を追加しています。また、トップページ上でパーツをドラッグ＆ドロップで直接移動できるようになったり、ワンクリックでメール内容の一部を抄録できたりと、インターフェース面での機能強化も豊富に搭載しています。私の個人的な感想としましては、痒いところに手が届き、使うほどにその使いやすさがクセになるようなイメージだと感じています。これらの機能も反応は上々で、既存ユーザーの方々からはぜひバージョンアップしたいという声をいただき、また、初めてみた方からも好印象を持っていただきました。

今回のイベントを通して実際にOffice8を触っていただくことで、また新たなご要望もいただきました。日々、画面と向き合っているだけでは見えてこない部分を気付かせていただける貴重な意見です。
たくさんの意見を考慮し、日々改良を重ねておりますのでどうぞよろしくお願いいたします。そして、Office8の来春リリースをお楽しみに！

お久しぶりです、田中です。

昨日、８８（パチパチ）キャンペーンのプレスリリースと一緒に、現在私たちが開発を進めている製品が「サイボウズ Office 8」というメジャーバージョンアップであることを公表させていただきました。ちょうど、日経BP社の顧客満足度調査で8回連続の部門1位をいただいたことと次期版バージョン番号の「８」をとって「パチパチ」というわけです。

この企画は、只今開発を進めているサイボウズ Office 7の次期バージョンのデモサイトを公開して、応募いただいた皆様の中から888名の方々にその環境へアクセスするアカウントをご案内するという内容です。開発を含めて初めての試みとなりますが、お試しいただく方々により便利なツールとして進化していく姿を楽しみながら体感していただけるように日夜開発を続けておりますので多くの方々にご応募いただければと考えております。

現行バージョンのサイボウズ Office 7では長くメジャーバージョンアップされていなかったこともあり、まずは日々運用に携わっている管理者の方々をターゲットにした強化が中心となりましたが、次のバージョンでは比率的にエンドユーザー指向の機能強化を多く取り入れ、管理者向け機能としてはセキュリティ機能の強化やトラブル時の原因調査にかかる時間を可能な限り短縮していくためのサポート機能などを盛り込んでいます。もちろんその他にも多くのご要望をいただいていた機能や新たにチャレンジしていく機能などここでは書ききれないほどの機能が盛り込まれています。また、そうした強化を経てもサイボウズらしく改まった教育がなくても新規の方もバージョンアップの方も十分に活用していただけるように細心の注意を払って開発を進めております。

今月一杯はデモアカウントの募集を行っておりますので
皆様からのたくさんのご応募を心よりお待ちしております。

デモサイトの公開を前に少しつづでも新たな機能、その仕組みを紹介していければと思っておりますのでどうぞお楽しみに！

岡田です。

現在サイボウズでは 「８」にちなんだキャンペーンを計画中 なのですが、せっかくなのでこのブログでも「８」にちなんで UTF-8 に関するお話をさせていただこうと思います。

昨年 Office 開発グループに配属され、自由課題で Office に Ajax アプリケーションを実装していた時の話ですが、Ajax で日本語のデータを送信すると文字化けが発生しました。

Ajax で日本語のデータを送信する場合、EncodeURIComponent() 関数などでURL エンコードする必要がありますが、この関数では自動的に UTF-8 でエンコードされます。
しかし、Office のデータベースの文字エンコーディングは Shift JIS ですので、そのまま保存して、そのまま取り出して表示すると文字化けが発生する、というわけです。

文字化けを発生させないためには、JavaScript で Shift JIS に URL エンコードできるようにするか、CGI で UTF-8 から Shift JIS に文字エンコーディングを変換（もしくはその逆を）できるようにするしかないのですが、どちらもなかなか大変な処理になってしまいます。

• JavaScript で Shift JIS に URL エンコードする方法
  Shift JIS のコード表を用意してShift JIS コードに変換する方法や、 Unicode から Shift JIS のマッピング表を用意して charCodeAt() 関数で Unicode に変換した後、Shift JIS に変換する方法などが考えられます。 しかし、いずれの方法でも巨大な表を常に読み込まないといけないので、パフォーマンスに影響が出てしまうのは避けられないところです。
• CGI で UTF-8 から Shift JIS に文字エンコーディングを変換する方法
  PHP には mb_convert_encoding() という気の利いた関数が用意されているのですが、C++ には用意されていません。もちろん、Windows では MultiByteToWideChar() 関数とWideCharToMultiByte() 関数を、Linux では iconv を使うという手もあります。 しかし、自分たちで一から作っておいた方が何か問題があった時にメンテナンスが楽なので、Unicode から Shift JIS のマッピング表を用意して、UTF-8 から Unicode に変換した後、Unicode から Shift JIS に変換する方法が無難かと思います。

結局のところ、文字エンコーディングの変換は C++ でコツコツ書くのが一番かなぁという結論です。

「サイボウズ Office」 プロダクトマネージャの山田です。

おかげさまで、「日経コンピュータ」誌 の「第１３回顧客満足度調査」グループウエアソフト部門にて、８回連続で１位を獲得させていただきました。

昨年、４年ぶりにメジャーバージョンアップを行いましたが、長い期間「もう面倒を見ないつもりか」という思いで待たれていたお客様も多かったと思います。
「サイボウズ Office 7」の開発にあたり、いつも「サイボウズ Office」を運用してくださっているシステム管理を行っている方にとって、必要な機能を用意することから始めようと思いました。おかげさまで、大きな迷惑をかけることもなく、順調にバージョンアップをしていただいており、製品に関わった者一同、本当に感謝しております。

ただ、「サイボウズ Office」は４年のブランクを経て進化を再開したばかりです。今回、高評価をいただいたのは「期待」の意味も大きいのではないかと思っています。この「期待」に、私たちが応えられるかについては、今後リリースする製品・サービスや、お客様へのサポートから判断していただき、足らないことがあれば、指摘していただきながら、お客様と共に成長したいと思っております。

今後とも、「サイボウズ Office」を、よろしくお願いいたします。

はじめまして、 8月1日より、Office開発チームに配属された新人の梅田と申します。

まだ配属されたばかりで、実際の開発にはこれから少しづつ参加していくことになりますので、
皆様にOffice開発の話題をお伝えするにはもっと多くのことを先輩方から吸収していかなければなりません。
そこで、今回はOfficeの開発に飛び込んできた私の意気込みをお伝えさせていただきたいと思います。

私が以前アルバイトをしていた某IT会社では、Office6を導入していました。
その会社では、Officeのスケジュール機能を使い、休みの申請をするようになっていました。
しかし、社内でのコミュニケーションは通常のWebメールで行っており、Officeの他の機能は一切使われていませんでした。
この時の私はグループウェアでどんなことができるのかを全く知らず、Webメールを使ってコミュニケーションするスタイルが当たり前だと思っていました。

実際にグループウェアの良さや便利さを知ったのはサイボウズに入社してからです。
グループウェアにはたくさんの機能があり、一から一つ一つ学んでいかないといけないため、使い始める前は少し抵抗がありました。
しかし、実際に使ってみると自分のスケジュールがすぐに確認できたり、空いている会議室を簡単に押さえることができたりと、
非常に便利なツールだということに気づきました。Webメールで行うよりも円滑に社内の人とコミュニケーションを行うことができ、
今まで自分が当たり前だと思っていた会社のコミュニケーションスタイルを覆すツールでした。

既にOfficeを導入いただいているユーザー様も多くいらっしゃいますが
まだ、Officeに触れる機会がなかったり、知っていただくチャンスがなかったりして
私の感じる便利さをお伝えできていない方々も多くいると思います。

そこで私がOffice開発でやっていきたいと思っているのは、ユーザー様に便利さやメリットが伝わりやすく、
今よりももっと「使ってみたい」「使ってみよう」と思っていただけるような製品へとOfficeを進化させていくことです。
お客様に便利に使っていただくのはもちろんのことですが、
使うという第一のステップをより多くの方に踏んでいただけるように励んでいきたいと思います。

次にこのブログを書く機会がありましたら、皆様の希望に応えることができるような
Office開発のお話をお伝えしたいと思います。
これからも宜しくお願いします m__m

田中です、お久しぶりです。

Webアプリケーションを開発していると仕様としてRFCを参照することが頻繁にあるのですが、実際の開発の中ではRFCに準拠しつつ個別にブラウザの癖を吸収しつつ進めることになって、なかなかRFCに準拠すればそれで問題なく動作するということにはなってくれません。
その中でも長い間悩まされているのが、ファイルダウンロード時の日本語ファイル名の付け方です。問題の元にあるのはファイル名に使われる文字列のエンコード形式を指定する方法がRFCで定義されていなかった、というところにあると思いますが、これがなかなかの曲者です。
ファイルダウンロード時の保存ファイル名を決める方法は、

1. URLにファイル名を付加する
2. Content-Dispositionヘッダでfilenameを指定する

1. IEの場合 左クリックして保存する場合も、右クリックして対象を保存する場合も共にファイル保存ダイアログが開かれる前にサーバーへアクセスし、Content-Dispositionヘッダがあれば必ずこれを参照します。 ただしContent-DispositionヘッダのfilenameはURLエンコードされたUTF-8文字列として解釈しますが、拡張子のない場合にはURLデコードされないようです。生のShift_JISコードで指定されているとShift_JISのままファイル名を解釈します。
2. FireFoxの場合 左クリックして保存する場合には保存前にサーバーへアクセスして、Content-Dispositionヘッダがあればこれを参照します。しかし右クリックして対象を保存する場合にはサーバーへアクセスせずにURLから保存するファイル名を決定します。Content-Dispositionヘッダのfilenameはそのままの文字列で保存ファイル名として使われ、RFC2231形式に対応している。

少し上に「ファイル名文字列のエンコード形式を指定する仕様がない」と書きましたが、現在はRFC2231という仕様がありFireFoxはこれを正しく解釈してくれるので、FireFoxからのアクセスの場合にはこの形式でファイル名をしているサービス、アプリケーションも現在は多いようです。
私たち開発者が頭を悩ますのは、上のようにIEはファイル名の解釈で独自の挙動を持っており、IEでもFireFoxでも正しく日本語ファイル名を解釈させようとするとContent-Dispositionヘッダのfilenameに生のShift_JISで指定するということになってしまうからです。RFCでは非ASCII文字をそのまま送信する仕様などありませんので違反といわれてしまっても止む無しという感じにもなります。
さらに困ったことには、Excel や Word には解釈できるURLの長さや、開く際のファイルパスの長さに制限を持っていて、日本語ファイル名をUTF-8でURLエンコードした場合にはURLやファイル名が長すぎてしまって Excel や Word などで開けなくなるということが発生します。このためにファイル名を切らざるを得ない場合なども出てきてしまい日本語に限定すると1文字を2バイトで表せるShift_JISの方がファイル名が切れにくくなるのです。

利用する立場からすると、保存したファイルがそのままダウンロードできるということはごく当たり前のことなのですが、こんなちょっとしたことですごく頭を悩ませたりすることになるのです。
いつかRFC2231で統一されるときが来るとは思うのですが、まだまだしばらくは悩ましい対応していくことになるのだと思います。

参考

畑です。

先日 Google から Google Protocol Buffer というデータ交換ツールがオープンソース化されました。

・ グーグル、XMLに代わるデータ交換ツール「Protocol Buffers」をオープンソース化

XMLに変わるものということですが、テキストである必然性がない場合であれば、つまりバイナリ形式でも問題ないのであれば、データサイズを小さくできるし、読み書き速度も上がるので良いと思います。

Java, Python, C++ に対応とのことですが、サイボウズ Office X も C++ で開発しているので、使えそうな場面がありそうです。

プロジェクトページの Quck Example を見るかぎりでは、ファイルストリームへの読み書きもサポートしているようなので、データベースに保存しないデータをファイルに保存する場合にも使えそうです。また、データベースへの保存においても、設定情報などを固めてBLOBのカラムに保存するような使い方ができそうです。

畑です。

以前、ハイブリッド・コンバーターと題して、現バージョンから次期版へのコンバートの方式に関するアイデアを説明しましたが、ちょうど今月実際のデータを使ったコンバート実験を行っているところです。

オンデマンドで、またはバックグランドでコンバートを行う旨の解説を以前の記事では行いましたが、最近はバックグランドで行う方向に傾きつつあります。そこで、バックグランドでの方式をもう少し詳しく説明したいと思います。

ユーザーの環境によっては、多数のユーザーで長い間サイボウズ Office シリーズを使用している環境もあれば、少数のユーザーで比較的短い期間しか利用していない環境もあるでしょう。蓄積されたデータのサイズが小さいユーザーであれば、バックグランドで行うといっても、すぐに完了してしまうかもしれませんが、サイズが大きいユーザーであれば動作しているマシンのスペックにもよりますが、何時間か、場合によっては１日以上時間がかかるケースがあるかもしれません。しかし、コンバートに時間がかかりすぎると業務に支障をきたすことになります。

そこで、バックグランド方式ではコンバートが完全に完了していないくても使用を開始できることを前提に考えています。コンバートするデータの順番に優先順位を付けておいて、使用開始に最低限必要なデータのコンバートが完了した後に、その他のデータを順次コンバートしていく方式です。そのかわり、コンバート中にアクセスしていてもトラブルが起こらないように設計する必要があります。

使用開始に最低限必要なデータとは、例えば以下のようなデータです。

・ システム設定データ
・ 個人設定データ
・ 未来のスケジュールデータ
・ 未完了のToDoデータ
・ 進行中のワークフローデータ

そして、その他のデータについては、参照頻度の高いデータが優先順位として高くなります。アプリケーション別にみていきますと、例えば以下のようになります。

・ 掲示板データは最終更新日時が近い順番に
・ 過去のスケジュールデータは昨日のスケジュールから順番に過去に

あと、バックグランド方式の場合、コンバート中にアクセスされることを想定するので、どの程度コンバートが完了しているかをアクセスしているときに表示する仕組みが必要であると考えています。

サイボウズ Office の PM を務めている山田と申します。初めまして。

PMとはプロダクトマネージャーの略で、サイボウズの各製品・サービスのコンセプトやビジネスプラン、そして製品要件を決める責任者です。今回は私が決めている「サイボウズ Office」の要件定義について、少々解説いたします。

「サイボウズ Office」の要件を考える上で、登場人物(「～が～できる」の「～が」の部分)を考えるわけですが大まかに以下のように考えています。

• システム管理者
  (「サイボウズ Office」システムに責任を持つ人)
• 運用管理者
  (「サイボウズ Office」のアプリケーションの運用を行う人)
• ユーザー
  (「サイボウズ Office」を使う人)

個人に提供するサービスであれば「ユーザー」を中心に考えるところですが「サイボウズ Office」の場合には、「システム管理者」を中心に考えています。
(もちろん「ユーザー」は、「システム管理者」「運用管理者」も含みます。)

「サイボウズ Office」は、「誰でも使いやすい」という評価をいただいていますがそれは、サイボウズの代わりに社内で「サイボウズ Office サービス」を展開している「システム管理者」の方々のおかげだと考えています。

そういう方々が、苦労しないように。
そういう方々が、使っているユーザーから感謝されるように。
そういう方々が、「情報を管理する」能力が向上するように。

そんなことを考えながら、要件を決めております。