Actions

Difference between revisions of "Mahara日本語ドキュメント/ロードマップ/ユーザビリティ"

From Mahara Wiki

< Mahara日本語ドキュメント‎ | ロードマップ
Line 16: Line 16:
 
一方、プルダウンメニューにはこれらの問題 (特に最初の問題) がありません。私たちはいくつかのプルダウンメニュー形式のメニューシステムを実装したいと考えています。また、同時に現在メインメニュー内にあるエントリーをタスクベースのメニューに変更したいと考えています。
 
一方、プルダウンメニューにはこれらの問題 (特に最初の問題) がありません。私たちはいくつかのプルダウンメニュー形式のメニューシステムを実装したいと考えています。また、同時に現在メインメニュー内にあるエントリーをタスクベースのメニューに変更したいと考えています。
  
Ray Merrillは3つのアイテムを配置するための3つのメインメニューを提案しました。大まかに言えば:「私のもの (My Stuff)」「他の人のもの (Other People's Stuff) 」 そして「共有 (Sharing)」です。This gives a task based approach, where we place items in the menus according to what people will be thinking when told to complete a task. For example, editing their profile page could appear under "Sharing", as it's all about sharing their information.
+
Ray Merrillは3つのアイテムを配置するための3つのメインメニューを提案しました。大まかに言えば:「私のもの (My Stuff)」「他の人のもの (Other People's Stuff) 」 そして「共有 (Sharing)」です。これはタスクを完了させるよう伝えるときにユーザが何を考えるのかを基にアイテムをメニューに配置する、タスクベースのアプローチを提供します。For example, editing their profile page could appear under "Sharing", as it's all about sharing their information.
  
 
</div><div id="section_2">
 
</div><div id="section_2">

Revision as of 15:07, 12 October 2011

作成中です - mits

このロードマップ内容、または早く実現するための財政的支援に関して、ロードマップおよび財政的支援フォーラム (英語)で議論しましょう。

Maharaは非常に使いやすいシステムですが、私たちのゴールはコンピュータおよびインターネットの経験が豊富ではないユーザとっても使いやすくすることです。以下、私たちがシステムに関して改善できる内容の一覧です:

メインナビゲーションの再デザイン

現在のタブシステムにはいくつかの問題があります:

  • 私たちが持っているアイテム以上に増やすことはできません。
  • 現在、Maharaプラグイン構造をベースとしているため、タスクベースのナビゲーションに変更することには全く向いていません。

一方、プルダウンメニューにはこれらの問題 (特に最初の問題) がありません。私たちはいくつかのプルダウンメニュー形式のメニューシステムを実装したいと考えています。また、同時に現在メインメニュー内にあるエントリーをタスクベースのメニューに変更したいと考えています。

Ray Merrillは3つのアイテムを配置するための3つのメインメニューを提案しました。大まかに言えば:「私のもの (My Stuff)」「他の人のもの (Other People's Stuff) 」 そして「共有 (Sharing)」です。これはタスクを完了させるよう伝えるときにユーザが何を考えるのかを基にアイテムをメニューに配置する、タスクベースのアプローチを提供します。For example, editing their profile page could appear under "Sharing", as it's all about sharing their information.

Horizontal Navigation

Along with redesigning the main navigation, horizontal navigation can provide a great usability boost by anticipating what actions a user might have intended to do when they visit a page.

For example, editing your profile and editing your profile View are two different pages. One is a form where you fill out basic information, while the other involves the View editor. However, a user may visit one, hoping to do the other.

In this case, horizontal navigation could provide a "Did you mean to?" sideblock, which has links off to other things the user might have been intending to do.

Terminology Changes

"View" and "Artefact" are fine terms to describe the system architecture - although the concept of things needing to be artefacts before they can be placed in a View is by now a long incorrect one. The problem actually arises in the UI, where it's hard to explain to a lay person what a "View" actually is. The word "artefact" also causes confusion. Most users couldn't care less that they're creating artefacts and can put them in Views - but they'll understand that they can create "stuff"/"information", and put it in "web pages".

We still need to discuss the best terms for this.

Icons for System Entities

The idea here is to display a 'group' icon next to group names, a staff icon next to staff members, etc. This helps reinforce the user's sense of what they're looking at, and in the case of users, point out exactly who has what role - most useful if the user is among strangers.

View Interface Improvements

The View interface as it stands isn't too bad usability wise (terminology notwithstanding), but there are still several things we could do to improve it:

  • Some kind of evidence of task progression, as you proceed through the View Creation process. This is a "step 1 of 3" type arrangement. Ray Merrill has previously mocked up a couple of examples of how this could look. It might be worth thinking about whether this makes sense as three separate pages requiring a wizard - possibly, doing it as a three-tabbed screen could provide another alternative?
  • Review of blocktype configuration. In Mahara 1.1, we changed the configuration of blocktypes to open up a modal window, rather than trying to display the form within the column. This means we have a lot more room to play with, so it is worth having a review of the configuration forms to see if they can be made simpler. As part of work going into Mahara 1.2, we are going to be using this feature to make it easier to browse files/folders using a tree browser.

Administration Section

There's a few issues with the Administration section as it stands right now.

One is that the Site Options form is growing longer and longer, with all sorts of options in it, with no real focus. If a user wants to change one of the settings, it's not logically grouped anywhere making it harder to find.

Another is that while plugins can provide configuration forms, to get to them you have to go hunting under Manage Extensions. Again, it can be hard to find a single setting, such as how to change the default quota for a user.

While the top level of the administration menu provides some task-based navigation, perhaps we should review exactly where each setting should go. It might be necessary to create new screens or wizards to make changing settings easier.