整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

干货:普通的中小设计团队如何快速制作有效的UI设计规范?

载自优设 欧巴酱


编者:这是一种简单快速制作规范的方法,已经在公司内部得到实践,可行性很高。适用于中小团队。

像优秀的设计规范比如Material Design / ANT Design等。

这里主要讲解如何快速制作一份设计规范。附件带工程文件和sketch插件。规范所用素材非工作设计界面,但不影响内容。关于设计规范的好处,这里不详细描述。

分析以往痛点



小结:规范落实起来难,效果就低很多,沟通成本加大,背离初衷。

问题场景

一家公司有30名设计师,4个前端开发团队,已有一份PDF规范。有趣的事情是,设计师的设计稿间距高度、字号、颜色用法有很大的个人习惯。有时还重复做已有的控件。然后开发爸爸们,同样也是,同一个可以复用的导航栏,侧边栏等,都重复去写了代码。小团队之间,都单独有自己的控件库,在UI验收时才能去解决,但是这无形中增加了成本。

我们能否减少这些问题呢,带着这些疑问,我也摸索出一点小经验。这也是我真正想要分享的内容。

首先确保团队已经使用Sketch办公。为什么用Sketch ? 关于这个问题,主要是效率方面高。

先出设计稿还是先出规范?

对于大多数小伙伴来说很疑惑,我也疑惑过。但是,你还没设计,怎么知道你真正想要的是什么颜色什么字号?这里我建议是,部分设计稿出来再做规范,然后慢慢的完善。

你说,公司已经有规范了怎么办,那可以把规范换一种方式呈现出来。

规范制作

这里主要以一个iOS设计稿为主,涉及到安卓的话,如果要精准,也时需要2份设计稿和2份设计规范。



这是一个Sketch制作的设计稿。我会简单做一个设定。



视觉规范

  • 颜色:界面用色/背景用色/文字用色/线条用色
  • 字号:标题字/正文字/辅助字
  • 行高
  • 间距



有小伙伴有疑问了,上面的色值那个C1/C2的代号是什么意思?

这个代号主要是为了方便前端开发人员建立UI库。比如,我们设计稿一个间距是20px,可能在开发眼里的20px和他所计算的单位不在一个频道。如果以J2来代号来表达一个间距值,那么不管双方是什么单位,但是至少这个间距大小呈现出来是一致的。当开发问设计人员某个地方间距是多少,你可以直接告诉他是J2,那么开发就会知道,哦,是20dp。

交互样式

  • 点击效果



组件库

  • 元素层:按钮
  • 组件层:可直接复用




比如,我们把设计规范做完了,如何去使用呢?

需要分2个方向,一个是UI,一个是前端。

设计师规范的使用



可以直接在sketch上面拷贝样式,或者直接Command C+V。还可以调出别的同事的画板,然后导入到自己的机子上。



插件名字叫做sketch palettes.可以上网搜索,可以下载的。

前端开发规范使用

他们没有sketch的前提下, 可以借用插件Marketch导出一个html格式。



导出后用浏览器打开index.html。




这样的呈现方式是不是比一个PDF文件要好呢?左边是类目,右边是相关的属性。也可以直接下载某些图标。



当设计规范建立,开发人员也建立了自己的UI库,然后再去推进之前剩下没有统一样式的小尾巴。

如果以后设计稿迭代怎么办?


要 - 面向用户的软件开发人员通常将图形用户界面(GUI)的模型转换为代码。因为 GUI 的变化与时俱进,这个过程既发生在应用程序启动时,也发生在演化环境中。麻烦的是,这种做法既具有挑战性又耗时。在本文中,我们提出了一种自动化的方法通过以下三个任务实现 GUI 的准确原型制作,从而实现了这一过程:检测,分类和组装。一,逻辑组件使用计算机视觉技术或模型元数据从模型工件中检测出 GUI 的数量。然后,软件库挖掘,自动动态分析和深度卷积神经网络可将 GUI 组件准确分类为特定于域的类型(例如,切换按钮)。最后,数据驱动的 K 最近邻算法生成合适的分层 GUI 可以自动组装原型应用程序的结构。我们在系统中为 Android 实现了这种方法称为 ReDraw。我们的评估表明,ReDraw 的平均 GUI 组件分类精度达到 91%,并且组装了原型应用程序,这些应用程序在视觉亲和力方面紧密地镜像目标模型,同时展示合理的代码结构体。与行业从业人员的访谈说明了 ReDraw 在改善实际开发工作流程方面的潜力。

索引词 - GUI,CNN,移动,原型,机器学习,挖掘软件存储库。

1.简介

大多数面向客户的现代软件以 GUI 为中心,依赖有吸引力的用户界面(UI)和直观的用户体验(UX)来吸引客户,促进有效完成计算任务。麻烦或美观的软件令人不快的用户界面成功的可能性很小,尤其是公司希望将自己的应用与具有类似功能的竞争对手。这种现象可以在移动应用市场中很容易观察到作为 App Store 或 Google Play,其中许多提供类似功能的竞争应用程序(也称为应用程序)功能(例如任务管理器,天气应用)通过 UI/UX 来区分自己。因此,重要的是正在开发任何基于 GUI 的应用程序的第一步和原型设计模型,这有助于 UI 的实例化和实验,以便进行评估或证明抽象设计概念。在工业环境中对于较大的团队,此过程通常由拥有特定领域专业知识的敬业设计师使用图像编辑软件制作引人入胜的直观 GUI 软件,例如 Photoshop 或 Sketch。这些团队是通常负责表达一致的设计语言在公司数字化业务的许多方面,包括网站,软件应用程序和数字市场紧缩材料。此设计过程的某些组件也倾向于延续到较小的独立发展通过创作实践设计或原型制作流程的团队吃线框或模型来判断设计思路之前承诺花费发展资源实施-给他们。这些初始设计稿创建后,至关重要的是,它们如实地被翻译成代码让最终用户体验设计和用户界面以其预期的形式。自动化原型制作过程 GUI 是一项艰巨的任务。这个困难的核心是需要弥合巨大的抽象差距从任一像素推理出准确的用户界面代码基于图形用户界面或数字设计的图形表示草图。

我们提出一种方法,将原型制作过程构造为以下任务:检测,分类和组装。第一项任务涉及检测-原子元素的边界框(例如 GUI-用户无法进一步分解的组件)实体模型设计工件(例如基于像素)的界面图片。可以通过以下方法解决此挑战:关于表示 GUI 组件的对象的形成直接从模型工件(例如,解析导出的元来自 Photoshop 的数据),或使用 CV 技术进行推断对象。一旦来自设计工件的 GUI 组件已被识别,需要将其分类为特定于域的正确类型(例如,按钮,下拉菜单,进度条)。本质上,这是图像分类任务,并且对该主题的研究已显示出巨大的近年来的进步,主要是由于深卷积神经网络(CNN)。但是,由于 CNN 是一种监督式学习技术,他们通常需要大量的训练有效数据,例如 ILSVRC 数据集。我们主张对应用程序进行自动动态分析从软件存储库中提取的信息可用于收集屏幕截图和 GUI 元数据,可用于自动最终得出带标签的训练数据。使用此数据,可以有效地训练 CNN 来对 GUI 实体模型中的组件(使用检测到的组件进行提取边界框)放入其特定于域的 GUI 组件类型。但是,组件的分类图像不是足以汇编有效的 GUI 代码。GUI 通常是在代码中表示为层次树,其中逻辑组组件捆绑在一起放在容器中。我们使用迭代 K 最近邻(KNN)算法和 CV 技术在挖出的 GUI 元数据上运行,以及屏幕截图可以构建现实的 GUI 层次结构,被翻译成代码。 我们已经实现了上述方法在适用于 Android 平台的名为 ReDraw 的系统中。我们从 Google Play 提取了 8,878 个最受好评的应用,使用全自动输入生成了这些应用程序从我们先前的工作中得出的方法(例如 GUI 抓取)关于移动测试。在自动应用程式执行期间,从每个应用程序中提取最受欢迎的屏幕浏览 GUI 层次结构。然后,我们在最受欢迎的原生 Android GUI 组件类型为在防雷屏上观察到。ReDraw 使用此分类器与迭代 KNN 算法和 addi-传统的简历技术来翻译不同类型的模拟将工件放入原型 Android 应用中。我们执行了一整套三项评估 ReDraw 的研究旨在测量(i)基于 CNN 的分类的准确性-分隔符(根据基线特征描述符和基于支持向量机的技术),(ii)相似度生成的应用程序到实体模型(在视觉上和在结构上),以及(iii)的潜在工业适用性我们的系统,通过对手机进行半结构化采访 Google,华为和 Facebook 的设计师和开发人员。我们的结果表明,我们基于 CNN 的 GUI 组件分类-sifier 的前 1 个平均精度达到 91%(即 CNN 预测的顶级类别是正确的),我们生成了应用程序与其模型具有高度的视觉相似性工件,生成的应用程序的代码结构相似到实际应用,ReDraw 有潜力改善并促进原型开发一些实用扩展的移动应用程序。我们的评估该部分还说明了 ReDraw 如何胜过其他相关移动应用程序原型开发一些实用扩展的移动应用程序。

总而言之,我们的论文的贡献有:

  • 引入新颖的原型制作方法植根于多种技术组合的软件 GUI 来自程序分析,MSR,ML 和 CV;和此方法在称为的工具中的实现适用于 Android 平台的 ReDraw;
  • 对 ReDraw 的综合经验评估,测量以下几个补充质量指标:与相关工作进行比较,并描述提要-从行业专家那里获得有关其实用性的反馈;
  • 在线附录展示了以下内容的屏幕截图:生成的应用程序并研究复制信息;
  • 作为实施 ReDraw 的一部分,我们收集了大量包含以下内容的移动应用程序 GUI 数据集屏幕截图和与 GUI 相关的元数据超过 14k 屏幕和超过 190k GUI 组件;
  • ReDraw 的公开开源版本代码,数据集和训练有素的 ML 模型。

2.背景和问题陈述

模拟驱动开发实践的第一个概念我们在本文中引用的是模型工件,即我们定义为:

定义 1-模拟工件:软件的工件-标明设计准则的标志和开发过程 GUI 及其内容。

定义 2-GUI 组件:原子图形元素具有预定义的功能,并显示在软件的 GUI 中软件应用。GUI 组件具有以下几种与域相关的组件之一类型,每种不同的类型都有不同的功能或美学目的。例如,在常见的网络应用中组件类型包括下拉菜单和检查盒子,仅举几例。

定义 3-GUI 容器:分组的逻辑结构成员 GUI 组件,通常定义空间显示其成员的属性。在以 GUI 为中心的现代应用中,GUI 组件很少使用预定义的坐标在屏幕上呈现。在-相反,容器的逻辑分组形成了分层结构(或 GUI 层次结构)。这些层次结构通常定义有关其组成成分的空间信息并在许多情况下会对尺寸的变化做出反应显示区域。例如,GUI-显示文本的组件可能会根据到其容器的尺寸。

有了这些定义,我们要解决的问题本文内容如下:

问题陈述:给定一个模型工件,生成一个打字应用程序,非常类似于模拟 GUI 在视觉上,以及在 GUI 层次结构的预期结构方面。

这个问题可以分解分为三个不同的任务,包括检测分类和 GUI 组件的功能化,以及现实的组装 GUI 层次结构和相关代码。在本文的范围内,我们专注于自动为移动应用生成 GUI 在视觉和结构上都相似(GUI 层次结构)。为此,我们调查了(i)现有应用程序;以及(ii)素描样机反向从现有的流行应用程序设计而成。我们利用这些类型的工件作为真实模型通常不是适用于开源移动应用,因此无法在我们的研究中使用。应该注意的是两种本文中使用的模型伪像可能无法捕获在创建过程中创建的模型中存在某些歧义一个真正的软件设计过程的过程。我们讨论这在第二节中的含义。

3.方法描述

我们将围绕以下内容描述我们用于 GUI 原型制作的方法:该过程分为三个主要阶段:检测,分类和部件。图 2 说明了该过程的概述我们将在整个方法说明中参考。在高层次上,我们的方法首先检测 GUI 组件通过使用 CV 技术或直接从生成的模型工件中解析元数据使用专业的照片编辑软件。二,分类我们将检测到的 GUI 组件转换为适当的类型使用从大规模收集的 GUI 数据训练 CNN 对提取的应用程序进行自动动态分析挖掘软件存储库。经过训练的 CNN 随后可以应用于模型工件以对检测到的组合进行分类要素。最后,构建合适的 GUI 层次结构(例如,GUI 容器中 GUI 组件的正确分组)我们利用了基于 KNN 的算法,该算法利用了 GUI-大规模动态分析中提取的信息组装一个现实的 GUI 组件的嵌套层次结构和 GUI 容器。为了说明我们的一般方法,在每个阶段,我们首先描述建议的方法,高层设计决策,然后讨论实现具体到我们的 ReDraw 实例的详细说明适用于 Android 平台。

3.1 阶段 1-GUI 组件的检测

GUI 原型方法所需的第一个任务是检测存在于实体模型中的 GUI 组件 tifact。此阶段的主要目标是准确推断原子 GUI 组件元素的边界框(在实体模型中基于像素的坐标项)。这样就可以将 GUI 组件的各个图像裁剪并提取以便在以后使用原型制作过程的各个阶段。此阶段可以是通过以下两种方法之一完成:(i)解析数据从模型工件中提取,或(ii)使用 CV 技术检测 GUI 组件。在以下小节中,我们将介绍这两种方法的检测程序作为我们在 ReDraw 中的特定实现。

3.1.1 从设计模型中解析数据

检测 GUI 组件的第一种方法是存在于模型工件中。鉴于 UI / UX 在当今时代的重要性面向消费者的软件,许多设计师和小型团队开发人员团队进行专业级图像编辑 Photoshop 或 Sketch 等软件来创建 GUI 的线框或像素完美静态图像包含模型工件。在此过程中,编辑或设计软件通常用于创建空白尺寸与目标设备屏幕匹配的画布,或显示区域(带有一些便于缩放的设计软件到多个屏幕尺寸)。然后,代表 GUI 组件作为可编辑对象放置在此组件的顶部画布来构建模型。这些工具大多数是能够以以下格式导出模型工件:编码有关画布上对象的空间信息,例如使用“可缩放矢量图形(.svg)”格式或 html 输出。有关对象布局的信息,包括这些对象的边界框,都可以解析从这些输出格式中获得高度准确的结果检测组件。因此,如果此元数据用于可用模型实体,可以对其进行解析以获得 GUI 组件的非常精确的边界框存在于模型工件中,然后可用于其余的原型制作过程。

给定在元数据中编码的空间信息,有时可以在模型制品中使用,有人可能会问:该信息是否也可以用于重建 GUI 组件的分层表示,可以以后有助于代码转换过程。不幸,现实的 GUI 层次结构通常无法被可行地解析至少由于以下两个原因而从此类工件中获取:(i)设计者使用照片编辑软件来创建模型,ups 倾向于编码与层次结构不同的编码由于设计师缺乏知识,开发人员会关于以编程方式的最佳方式在屏幕上排列 GUI 组件;(ii)限制在照片编辑软件中可能会禁止创建 pro-语法正确的空间布局。因此,任何分层从此类工件中解析出来的结构很可能是特定的设计师的喜好,或根据容量限制照片编辑软件的功能,限制了我们的原型场景。例如,设计师可能没有提供足够的 GUI 容器来创建有效的反应式移动版式或照片编辑软件可能不会允许按比例缩放 GUI 组件的相对位置跨不同的屏幕尺寸。

3.1.2 使用 CV 技术进行 GUI 组件检测

从模型中解析信息会导致高度 GUI 组件的准确边界框此信息由于以下方面的限制,可能并非始终可用使用的照片编辑软件或设计不同的照片实践,例如以数字或物理方式绘制模型使用数位屏,数位板或纸。在这种情况下,伪影可能只包含一张图片,因此 CV 技术-需要标识相关的 GUI 组件信息的工具。为了支持这些情况,我们的方法建立在中的 CV 技术来检测 GUI 组件边界盒子。此过程使用了一系列不同的简历技术(图 2 -1)来推断对象周围的边界框响应图像中的 GUI 组件。首先,坎尼的边缘检测算法用于检测边缘图像中的对象。然后将这些边缘扩张合并边缘彼此靠近。最后,那些轮廓边用于导出原子周围的边界框 GUI 组件。合并基于文本的其他启发式方法使用光学字符识别(OCR)的组件是用于合并文本的逻辑块的边界框(例如,与其将每个单词都检测为自己的组成部分,句子和文本段落合并在一起)。

3.1.3 ReDraw 实现-GUI 组件检测

在实施 ReDraw 时,要支持以下情况:可以从适用于 Android 的模型中收集元数据我们针对使用 Marketch 创建的文物的应用程序 Sketch 的插件,可将模型导出为 html 和 javascript 的组合。素描很受欢迎在移动开发人员之间,并提供广泛的自定义功能大型插件库中的内容。ReDraw 解析包含在其中的 GUI 组件的边界框导出的 Marketch 文件。支持与元数据相关的场景实体模型不可用,ReDraw 使用 CV 技术自动推断组件的边界框从静态图像。因此,GUI 的输入-ReDraw 的组件检测阶段是屏幕-镜头和相应的插销文件(3 月 ketch 解析程序已应用)或单个屏幕截图(已应用基于 CV 的技术)。最终结果 GUI 组件检测过程是一组边界位于原始输入屏幕中的框坐标-镜头和从原始图像中裁剪出的图像集合根据派生的边界框截图描述原子 GUI 组件。稍后将提供此信息到 CNN 中分类为 Android 特定组件阶段 2.2 中的类型。请注意,只有 GUI-在此过程中检测到组件。在另一手工 GUI 容器和相应的 GUI 层次结构在第 2 节中描述的组装阶段构造。

3.2 阶段 2-GUI 组件分类

一旦原子 GUI 组件的边界框已从实体模型工件中检测到错误,下一个原型制作过程中的步骤是对裁剪后的图片进行分类特定 GUI 组件的年龄进入其特定领域类型。为此,我们提出了一种基于数据的基于机器学习的方法利用 CNN 的方法。如该图所示。2-2.1 和图 2-2.2,此阶段包含两个主要部分:(i)大规模软件资源库挖掘和自动动态分析-sis,以及(ii)CNN 的分类训练和应用 GUI 组件的图像。在以下小节中我们首先讨论的动机和实施之前的资源库挖掘和动态分析过程讨论使用 CNN 的基本原理以及我们的具体 ReDraw 中的体系结构和实现。

3.2.1 2.1 阶段-大规模软件存储库挖掘和动态分析

鉴于其受监管的性质和深入的架构,CNN 针对图像分类任务需要大量训练数据以实现精确分类。训练传统 CNN 图像分类网络的数据典型 ic 由大量标有它们的图像组成对应的类别,其中标签对应于优先级图像中的玛丽主题。传统上,此类数据集具有人工采购,其中人类费力地标记数据集中的每个图像。但是,我们建议自动创建标签火车的方法包含特定 GUI 组件的图像的数据从完整的屏幕截图和对应的标签中裁剪其特定于域的类型(例如,按钮或微调框 Android)使用全自动动态程序分析。我们对自动化动态分析的关键见解过程如下:在自动探索软从大型存储库,平台特定框架中挖掘的软件可以用来提取描述 GUI 的元数据,然后可以将其转换为适合的大标签训练集 CNN。如图 2- 2.1 所示,此过程可以通过挖掘软件仓库自动提取可执行文件。然后进行大量有关自动输入的研究可以使用基于 GUI 的应用程序测试生成通过模拟用户自动执行挖掘的应用程序-输入。例如,如果目标是移动应用,则输入生成技术依赖于基于随机的策略可以用于此任务。作为应用程序执行后,屏幕截图和与 GUI 相关的元数据可以为每个观察到的独特屏幕自动提取或应用布局。其他类似的自动 GUI 翻录或爬网方法也可以适用于其他平台例如网络。可以使用第三方软件捕获屏幕截图或目标操作系统随附的实用程序。图形用户界面可以从各种来源收集相关的元数据包括可访问性服务,html DOM 信息-或 UI 框架(例如 uiautomator)。的然后可以使用 GUI 元数据和屏幕截图提取 GUI 组件的子图像及其标记的类型从描述每个屏幕的相关元数据中解析。结果数据集的基础质量与标签如何很好地描述了 GUI 组件的类型显示在屏幕上。鉴于许多软件 UI 框架,可用于挖掘此类数据直接从呈现工具中提取信息屏幕上的应用程序 GUI 组件,此信息可能非常准确。但是,有一些从这些框架中收集信息的情况-作品包含轻微的错误或无关的情况。我们讨论这些情况和可采取的缓解措施他们在 3.2.4 节。

3.2.2 ReDraw 实施-软件存储库-和自动化动态分析

采购大量 Android 应用来构建我们的我们开采的 CNN 的培训,验证和测试语料库 Google Play 上的免费应用程序。为确保代表提取的应用的情感性和质量,我们提取了截至 2017 年 6 月 Google Play 商店中的所有类别。然后,我们筛选出主要包含游戏,因为游戏倾向于使用非标准类型的 GUI,无法自动提取的组件。这个离开我们共有 39 个类别。然后,我们使用了 Google PlayAPI 库,可从每个库下载前 240 个 APK 类别,不包括一个以上存在的重复项类别。这导致了总共 8,878 独特的 APK 之后解释跨类别交叉列出的重复项。

要从挖出的 APK 中提取信息,我们会补充了一个大型动态分析引擎,称为使用系统自动化的执行引擎基于我们先前工作的输入生成方法 CRASHSCOPE 和 MONKEYLAB 至充实应用程序并提取屏幕截图和与 GUI 相关的内容有关已访问屏幕的信息。更具体地说,我们的系统 GUI 探索在以下位置导航目标应用程序的 GUI 以深度优先搜索(DFS)的方式锻炼可轻敲的内容,可长时间敲击且可键入(例如,能够接受文本输入)组件。在系统的探索中,我们使用 Android 的 uiautomator 框架提取与 GUI 相关的信息作为描述层次结构的 xml 文件以及给定显示的组件的各种属性屏幕。我们使用 Android screencap 实用程序来收集屏幕截图。该 uiautomator XML 文件包含各种显示的每个 GUI 组件的属性和属性在 Android 应用程序屏幕上(包括边界)框(例如,屏幕内的精确位置和区域)和组件类型(例如 EditText,ToggleButton)。这些属性可为每个 GUI-提供单独的子图像显示在给定屏幕上的要从中提取的组件相应的屏幕截图并自动标记为带有适当的类型。

DFS 探索策略的实施利用状态机模型,其中考虑了状态唯一的应用程序屏幕,如其活动名称所示并使用以下命令提取显示的窗口(例如,对话框)在 ADB 壳 dumpsys 窗口命令。考虑到超过 8.8k 个应用中可行的执行时间我们的数据集,同时仍在探索几个应用程序屏幕,我们将我们的勘探策略限制为每次执行 50 次操作应用程式。先前的研究表明,大多数自动输入 Android 的生成方法趋于达到峰值覆盖率(例如,约 20%到 40%的语句覆盖率)经过 5 分钟的探索。而不同的输入生成方法往往表现出不同的数量给定时间单位的操作数,我们过去的工作表明我们的自动输入生成方法可以实现有竞争力的覆盖率,以及我们的规定每次 50 动作的舒适时间超过 5 分钟应用程式。此外,我们的目标是进行大规模分析不是要完全探索每个应用程序,而是确保各种屏幕和 GUI 组件类型。对于每个应用程序,执行引擎提取 uiautomator 前六个唯一屏幕的文件和屏幕快照对每个应用程序的屏幕数量参观了。如果给定的数量少于六个屏幕应用程序,然后收集所有屏幕的信息。我们的大型执行引擎以并行方式运行,中央调度员向工人分配工作的地方,每个工作人员都连接到一个物理 Nexus 7 的地方平板电脑,负责协调执行传入的工作。在动态分析过程中,每个工作包括系统地执行来自我们的数据集。当工人完成工作后,通知调度员,调度员又分配新的工作。此过程在 5 名工人上并行进行,直到所有我们已经研究了数据集中的应用程序。由于广告在免费应用程序中很受欢迎,通常是动态 WebView 而非本机组件组成,我们使用 Xposed 来阻止应用中的广告使其他类型的本机组件模糊。

3.2.3 2.2 阶段-GUI 组件的 CNN 分类

收集了标记的训练数据集后,我们需要训练一种机器学习方法来提取显着特征从 GUI 组件图像中进行分类基于这些提取特征的图像。去完成我们的方法利用了 CNN 的最新进展。的与其他图像分类相比,CNN 的主要优势方法是该架构允许自动执行从图像数据中提取抽象特征的逼近非线性关系的应用原理数据局部性和端到端可训练的分类建筑。

3.2.4 ReDraw 实现-CNN 分类器

一旦目标实体模型中的 GUI 组件具有使用模型元数据或基于 CV 进行检测技术,ReDraw 必须有效地将这些组合阵营。为此,ReDraw 实施了 CNN 将 GUI 组件的目标图像分类为观察到的 15 种最受欢迎的组件之一在我们的数据集中。在本小节中,我们首先描述数据-用于生成培训,验证和测试数据集(示例如图 4 所示)在描述我们的 CNN 架构和培训之前我们采用的程序。

数据清理:我们实施了多种类型的预备降低噪音的处理和滤波技术。更多具体来说,我们在三个阶段实施了过滤流程不同的粒度级别:(i)应用程序,(ii)屏幕和(iii)GUI 组件级别。

3.3 阶段 3-应用程序组装

原型制作过程的最后任务是组装应用程序 GUI 代码,包括三个阶段:(i)建立适当的组件和容器层次结构,(ii)从目标实体模型推断出样式细节,(iii)组装应用程序。

3.3.1 推导 GUI 层次结构

为了从的分类集合中推断出现实的层次结构组件,我们的方法利用了 KNN 技术(方法 1)用于构建 GUI 层次结构。该算法采用表示检测到的和分类的 GUI 组件的集合作为单个级别树(InputNodes)中的节点作为输入。然后,对于我们从自动化收集的数据集中的每个屏幕动态分析,Alg。1 次首先提取一组 TargetNodes 的对应于 InputNodes,它们是算法第一次通过的叶节点里特姆。接下来,将 InputNodes 与每个使用基于以下内容的相似性指标提取(TargetNodes)屏幕所占据的屏幕区域的并集交集(IOU)重叠成分(ALG 的边界框。1 -line5)。通过选择一个匹配的屏幕 InputNodes 之间的最高 IOU 组合得分最高和 TargetNodes。然后,父容器组件

3.3.2 推断样式并组装目标应用

为了从模型中推断出样式细节,我们的方法采用色彩量化(CQ)的 CV 技术,和颜色直方图分析(CHA)。对于 GUI 组件其类型不表示他们正在显示图像,我们的方法量化了每个图像的颜色值像素并构建颜色直方图。最受欢迎颜色值可用于通知样式属性生成代码时的组件。例如,对于显示文本的组件,最流行的颜色可以是用作背景和第二最普遍的颜色可以用于字体。

3.3.3 ReDraw 实施-App AssemblyReDraw 使用 KNN 组装 Android 应用程序 GUI 层次结构构建方法(请参见第 3.3.1 节)和基于 CV 的颜色样式检测。输入到 Alg。1 是来自 CNN 的一组分类的“叶节点”组件,以及输出为 GUI 层次结构。为提供足够的数据 KNN 算法,一个语料库,包括来自从中挖掘的 GUI 层次结构的“清理”屏幕我们构建了大规模的动态分析过程。这个语料库形成 InputNode 到的数据集 TargetNodes 组件在层次结构构建期间匹配 tion。KNN 为目标生成的 GUI 层次结构然后使用“叶节点”组件来推断风格细节来自原始的模型工件。更具体地说,每个组件和容器,我们执行 CQ 和 CHA 提取每种成分的主色。对于有文字元素的组件,我们将光学使用开源 Tesseract 进行字符识别(OCR)在原始屏幕快照库中获取字符串。

4 实验结果

4.1 RQ1 结果:CNN 的有效性

ReDraw 基于 CNN 的 GUI 组件分类器能够获得较高的平均精度(91%),并优于基线 BOVW 方法的平均精度(65%)。

4.2 RQ2 结果:层次结构构建

ReDraw-Mock Up 能够生成与真实层次结构相似的 GUI 层次结构,而不是 REMAUI 或 pix2code。这一信号,重新绘制的层次结构可以被开发人员使用的低努力。

4.3 RQ3 结果:视觉相似度

与目标截图相比,ReDraw 生成的应用程序具有很高的视觉相似性。

4.4 RQ4 结果:工业适用性

ReDraw 有望应用于工业设计和开发工作流程,特别是在进化环境中。然而,模塑最有可能是必须作出适合具体工作流程和原型工具链。

致谢

本文由南京大学软件学院 iSE 实验室 2020 级硕士研究生张晶翻译转述。

者:林间有影落

作为设计师,一个老生常谈的话题就是还原度检查。

还原度检查:也叫还原度验证、设计走查、设计验证。是保证研发实际实现的效果是否和设计稿一致的过程。

借一位建筑设计师写的话来说,“画一张效果图很容易,但项目得以高完成度的还原却很难。” 如果你的设计不是仅仅停留在纸面,那你就需要面临最终的设计还原度问题。

在进行还原度检查中,你是否有听到过这样的话:

“我这样实现也行吧,我觉得比你设计还好点。”
“这里还不对吗?我已经改了好几遍了……“
“项目时间太紧了,我们先实现功能吧。”
“不就几个像素吗?差不多行了。”
“我觉得是一样的,你行你上?”

……

这些其实并不是个例。

在设计还原度检查的过程中,我们常常会遇到这样或那样的问题,令这个过程耗费精力无数,最终收效却并不大。听闻一位设计师说他们某个项目,最终耗费了 30 人/天的时间去做还原度验证。

设计的项目还原度如何,是每一位设计师成长的必经之路,也是设计师能力的一种重要体现。说到这里,你可能有点疑问,明明是研发实现的问题,怎么成了能衡量设计师能力的一种体现呢?

诚然,在同等条件下,优秀的研发工程师能够凭借自身实力和丰富经验实现更高程度的设计稿还原,同样的,优秀的设计师也可以凭借着自身实力和丰富经验,保证自己的设计稿具有更高的还原度,这是一个相互影响的过程。

所以,本质上,设计还原度,还是一个合作问题。

而 B 端+AR,其本质也是一样,是建立在设计还原度检查的通用场景上的一个特殊场景。接下来的文章,我分五个部分来进行说明。

要检查的内容都有哪些呢?

我认为,整个设计还原度检查可以分为三个部分:

1. 交互内容

交互内容紧扣功能,但和测试不同,主要是以用户的使用流程来检查相应功能下的交互逻辑是否完整实现,反馈和提示是否有遗漏,使用时的合理性和可用性是否与设计初衷一致。

AR 中还应多关注各种交互转换中的相对参照分类是否正确。

2. 视觉内容

前端页面的静态效果是否和设计稿一致,包括色彩、布局、排版等细节,这块内容一直是研发和设计难以达成一致的重灾区。

在 AR 应用中,还要包括三维内容的大小、材质等细节。

3. 整体体验

AR 设计是虚实结合的设计,我们实际设计时虽然只能着眼于虚拟元素,但用户所体验到的是结合真实环境的虚实结合界面,所以特定环境下的整体体验检查也是必要的。

我做的项目由于一般是一整套系统,通常存在多个终端数据联动,比如 web 平台和 AR 应用的联动,那它们之间的交互是否符合设计需求,是否有遗漏和错误,也属于整体体验的检查内容。

什么时候做还原度检查最适合呢?

为了效率最大化,我推荐是产品提测后再进行设计还原度检查,如有条件,最好在测试团队完成第一轮功能测试后再介入。
原因有三个:

  • 第一,一般功能性的 bug 会更为紧急,因为它大多会导致产品在该功能上存在完全不可用的状态,这个时候就算设计师介入去做还原度检查,也很难检查到设计本身的问题。
  • 第二,在改动功能型 bug 的时候,会使某些已经修改的还原度问题复现,加重了反复查验的工作量。
  • 第三,一些很明显的交互和视觉问题,其实测试团队是能够帮忙测出来的。

检查到什么程度?

这个其实没有非常硬性的标准,不同公司、不同项目、不同设计师都可能不一样。有的认为 95%以上还原度才能达到标准,有的认为 90%甚至 80%就算达到标准。

一般来说,还原度标准:C 端>B 端>后台。

而 AR 应用的还原度即使在 B 端,也应该大于通常的 B 端应用,因为在当前技术水平下,许多 AR 应用首要满足的是展示目的,交互和视觉的最终效果是非常关键的。

常见问题?

在设计还原度检查中,我们常常遇到这样或那样的问题,归纳起来,有下面几点。

1. 设计输出有缺失

输出的缺失主要体现在两个方面,是一个是内容本身的缺失,一个是附加说明的缺失。

内容本身的缺失,指设计输出里缺少某些细节交互的说明,界面不同状态的展示,不同状态的按钮或图标切图,动效说明等。这个可以靠设计师的细心和对设计的自查来避免。

附加说明的缺失,主要是标注的问题。随着行业的发展,现在已经有很多自动标注和切图工具了,但正因为如此,反而容易因为懒,缺失很多需要手动补充的信息标注。

2. 设计处理不规范

设计处理不规范,主要是指自由发挥,完全不考虑研发的实现难度和整个项目的目标。有些设计稿乍一看质量上乘,如果作为停留在纸面上的作品甚至相当优秀,但是 UX 设计毕竟不是纯艺术,而是用来解决问题的方案,需要掌握平衡。

3. 研发没有理解设计的逻辑

由于每个人的角度不一样,即使输出的设计文档在设计师眼里看起来再详尽,在研发人员的理解下也可能完全不一样。

4. 研发和设计师优先级认知不一致

如果说没有理解带来的现象是研发工程师认真的做了,但没有做对。那这一点带来的现象就是他明明可以做好,却总是不好好做。也就是我们常常吐槽的研发人员“不配合”。这里的不配合,其实就是两方在优先级认知上不一致,你提出的还原度问题,他觉得没什么关系。既然无关重要,何必浪费精力?毕竟,哪个研发工程师身上不背几个 bug。

5. 还原度检查不完整

该检查的内容没有检查到。原因可能有自己的,也可能有外部的。比如在 AR 设计中,我们经常会遇到很难完美复现 AR 应用真实环境的问题。又比如在某个 To B 项目中,由于 web 平台的联动终端是机器人,我很难在某些与机器人强联动的界面上进行整体的体验检查。

怎么做得更好呢?

为了有效保证还原度,我们可以做的事情有很多,我总结了 7 点:

1. 重视设计规范

第一、有规范。第二、符合规范。

有规范,指整个设计有自己的规范定义,同类的元素使用相同的规范来呈现,具有一致性的间距、大小、色值设定等。比如同样表示“可用”/”不可用“的标签,在所有的界面,都应该是一致的视觉元素,包括样式、颜色、文字、间距、大小等。

符合规范,指符合研发语言的基本规范定义,比如可行情况下尽量使用该语言下的常用标准框架,定义最小单元网格(一般 4px,6px,8px 等),切图或间距等尽量以此为倍数;不要出现奇数等。这些都可以提高研发的效率。

设计规范的好坏,直接影响到后面的设计宣讲和设计输出的好坏。

2. 了解开发思维

了解开发的思维,在做设计稿的时候就可以换个角度看问题,足以让自己在后面的还原度检查中更省心省事。

首先是最简单的盒子模型。

盒子模型是 CSS 语言中的术语, 又称框模型 (Box Model) ,所有 HTML 元素可以看作盒子,是用来设计和布局时使用。CSS 盒模型本质上是一个盒子,封装周围的 HTML 元素,它包括:边距,边框,填充,和实际内容。 盒模型允许我们在其它元素和周围元素边框之间的空间放置元素。

图片来自网络

然后是 AR 设计中常用的 U3D 工具。这款工具可以使用多种语言来开发,它的布局可以分为三种方式:固定像素、根据屏幕大小进行缩放、固定物理距离。

固定像素,忽略屏幕的大小根据 UI 元素的实际像素显示 ,像素大小始终不变,即一个 100×100 的图片在任何的分辨率下都占用 100×100 的像素。一般 PC 上会使用这种方式,因为 PC 端分辨率差异并不大。

根据屏幕大小进行缩放,是研发最常用的一种,会根据设备真实分辨率与设计分辨率来对 Canvas 进行缩放。有三种模式:

  1. Match Width or Height
  2. Expand
  3. Shrink

固定物理距离,忽略屏幕大小和分辨率根据 UI 的实际物理大小来显示。

3. 宣讲设计逻辑。

不管是和设计评审一起还是私下对接研发,都要对自己的设计逻辑和输出内容做讲解,讲解的内容包括:通用的设计规范、资源图的命名规则、特别事项的注意等等。

讲解的目的就是让他理解你的设计逻辑。

通过讲解,研发人员明白这些设计的内在意义,知道为什么要这样做,才能够帮你把设计实现得更好。同样,宣讲设计逻辑的时候一定要要求具体的研发工程师到场,这会提高后面一系列工作的效率。

想一想,当你把自己辛辛苦苦,连几个像素一点点色差都要纠结半天作品托付给另外一个人,不该嘱咐嘱咐几句:“亲~这非常重要,值得你好好对待。”

4. 完善设计输出

完整的设计输出,应该包含承接产品需求文档的交互说明、视觉说明(含标注)和相关资源。

交互说明,应该写明可点击部分跳转的界面,不同状态下的中间过程,特殊情况下的界面处理等等。

视觉说明,应该包含对规范的说明和帮助研发实现界面的标注。

(1)规范的说明,需要设计师梳理通用的内容,让工程师对项目的前端界面样式有个整体了解,快速查找和定位到具体页面的基础样式(如:标准色、标准字、按钮等),也可以让研发工程师清楚的知道哪些内容我只要兢兢业业的调一遍,就可以复制到其他地方了。

AR 应用主要使用 U3D 研发,不像普通的屏幕 UI 有诸如蓝湖、摹客、marketch 这些标注工具自动翻译,我所遇到的工程师大多倾向于把设计师的效果图放到正视图下的状态,再用切图的元素一个个界面拼出来,如果研发能知道有些界面通用一套“拼图法则”,那会省事很多。

(2)标注部分,除了交给自动标注软件标注的部分,还应该将无法自动标注出来的内容通过手动标注补齐,这些内容包括但不限于:

  • 动态内容的标注

图片来源: https://juejin.cn/post/6844903712331137037 ©️微信小程序规范V1.0

比如:绝对位置和相对位置的注明。

上面这张图,A 类标注就可以用自动标注精确到像素完成,而 B 的标注因为不同屏幕大小不同,其实只要保证两个 B 相等就可以,那这里就需要手动注明了。

在 AR 应用中,由于涉及到三维空间,相对参考物尤为重要,首先要保证研发知晓当前界面里每个元素的参照对象(关于 AR 界面按参照物的分类),然后,再按照百分比来进行标注。

当然,也可以更为精确的使用当前 Z 轴下的物理尺寸来进行标注,但需要一些转换会比较难以把握。标注的这个部分,是和了解开发思维相辅相成的,当你了解开发思维后,就能够标注出更符合研发人员要求的说明。

相关资源,是指研发所需要的视觉元素资源。相关资源按照一定的规范命名,方便研发人员查找使用。

值得注意的是,在 AR 应用的设计中,视觉不仅仅指二维视觉(GUI)的说明和相关资源,还应该包括三维视觉内容的必要说明和相关资源。为了更好的模拟实际研发后的效果,尽量还原用户可见界面,推荐在视觉设计输出时添加环境照片。

设计输出是设计体现的书面形式,是整个设计交付非常重要的一环。好的设计输出让你交付研发时可以放心大胆的说一句:“亲~你还有不懂的可以看文档哦,别有事没事都来烦我如果有问题可以再找我。”

5. 了解检查目标

前面我们说过,还原度验证的标准一般 C 端大于 B 端大于内部后台,AR 应用由于其特殊性,即使交付 B 端的 AR 应用也一般要高于普通 B 端的还原验收标准,在此基础上,可以根据项目公司业务和项目实际情况来确定一个基准。

分清轻重缓急,避免体验问题被搁置,或者好改的体验问题被改了,而比较重要的体验问题,反而因为不好改反而遗留下来。

图片来源: https://www.shangyexinzhi.com/article/4211627.html

6. 选用合适工具

现在市面上已经有一些工具帮助设计师进行还原度检查,这里简单的举例 2 个。

Css Peeper: https://csspeeper.com/

它比浏览器自带的 Css 代码检查更适合设计师,不仅可以看到元素的常规属性,比如颜色、背景、间距;还可以看到元素的盒子模型,可以看到元素的 Padding、Margin…

Copiexl: https://copixel.bytedance.com/

字节出品的一款走查插件。

通过在网页上放置设计稿图片检查设计稿与开发结果是否完全重叠来判断开发的还原精度,精确到像素实现高质量的项目还原效果。

7. 记录总结情况

在项目发布之前,很多情况下体验问题可能得不到全部解决,这个时候,总结现有的设计还原程度,明晰重点问题及可能产生的体验风险,能够帮助整个项目快速了解现状,决策任务优先级。对于其他遗留的问题,也能够有机会进入下一轮迭代中。

· · ·

还原度的本质是一个合作问题,只有设计质量硬,配套产品全,在与研发合作的过程中活用我们的用户思维,才能让我们的设计作品得到更高的还原度。

注:本文来源于网络,如有侵权请及时联系我们。