ui gui

交互设计－图形界面

现项目适用设备平台显示组件分辨率仅有 128x64，颜色深度仅有 1 位（单色）。相信当今很多人不会考虑将这种设备作为交互主要界面，因为现在有很多更好的显示组件可供选择；不过，回想一下过去十年内的很多简易设备（或以流行说法称之“嵌入式设备”），以这种低分辨率设备作为主要界面的应用场景不在少数，比如：电子表、MP3播放器等等。在低端范畴，即使当今，使用这种组件作为交互主要界面的应用场景仍有不少，比如：家用电器面板等等，甚至某知名路由器居然在路由顶端设计了一个“唔等使”的灰度串口屏幕。

在分辨率有限的场景，屏幕不再像 PC 端一样可以展示丰富内容，每一个像素点对于应用程序来说都是宝贵的。即使分辨率如当今手机屏幕之高，为了聚焦功能，图形界面亦不像 PC 端杂乱，通常一个应用程序占用整个屏幕的可绘图空间（工具栏或虚拟按键等除外）。

PC 端图形界面交互设计中以窗口为基础，每一窗口嵌套各个子窗口（BeOS API 称为 View），继而显示足够丰富的各项内容。但基于以上考量，本项目的图形界面交互设计（GUI）以页视图（PageView）为基础，每一个页视图，其可操作屏幕空间即为整一个屏幕。另外，在页视图（PageView）切换的基础上，再引入视图（View）的替身模式，好比如一个普通的社团组成：

• 带头大哥

在这里是 App，负责各种事件监控及派发。

• 小头目

在这里是 PageView，负责安排具体事物。

• 喽啰

在这里可以是 View，也可以是 PageView，头目（PageView）有事时随时可以 StandIn（顶替），但所使用资源都来自于头目（PageView），事情作毕即 StandBack（归位），由头目继续担当，事情施为期间大多细节头目亦均知悉。

替身模式

项目总体设计时，尽量避免坠入 PC 端图形界面交互设计的那种繁杂视图模式。但是，具体应用界面呈现时，单一页视图（PageView）若集合所有功能的话，代码将变得庞大且难以管理。故此多次取舍，仍然借鉴 BeOS API 的 Interface Kit 思路，但由于项目适用设备的特殊性，原子视图（View）模式不适合项目采用。因而，我们排除“同级视图并存”的 PC 端图形界面特点，变换成为简洁的“替身模式”，即只允许一个替身视图呈现。

仍以上述社团组成来对这种模式进行类比；负责安排具体事物的头目若然事事亲历亲为，效率或者效果会有一定折扣，管理者可以是全才，但决不能全为，做好自己本分即可。这样下来，事情就分派给底下喽啰去做，谁有本事谁顶上，但必须有个前提：同一阵线上（归属同一 BLooper，事件处理在同一线程）；即使部下能力或条件不足，进行外包处理，需要通过国际安全线路进行联系（用 BMessenger 等传递消息），但是呈现出来的仍然应该是本帮兄弟。