LBS设计笔记

地图可视化应用可以划分为大屏展示应用与小屏的互动应用。这里更广义的将其划分为数据展示功能与探索交互功能。

LBS自助分析可参考的demo:deck.gl。其于大屏生编辑器的区别在于地图可以编辑多个图层,自定义每个图层的数据、支持选取各种图形以及视觉通道到数据的映射。添加filter,双向、或单向的图表互动。

dataV的图表生成流程是错误的,不利于分析问题。调研quickBI.

数据展示功能

  • 散点图、折线图、面积图、热力图
  • 单点/区域/全局的数据展示

Insights(异常检测、趋势检测;异常放大可视化与趋势放大可视化)

这里借助可视化的视觉欺骗技巧来帮助用户在难以快速聚焦问题的地图可视化中聚焦到想要分析的问题。

维度层级定义(深度)
导数(微分)
积分
向量/梯度

等高线、3D高度图被自动填补的点的具体含义?

Read more
BI研发反思

所有人都告诉我Canary是一款玩具,但是没人要告诉我为什么,该怎么做。

Canary从诞生到现在已经有1年多了,从最初的单纯的数据映射工具到自助分析功能,中间改版过无数次、无论是交互的大的调整还是架构的重新设计都经历了很多。但Canary从来没有创造过价值,从来没有在真实的落地场景中为客户发现问题、带来增益

在导师那里打工时,一直告诉我,他希望我能做一款真正可以投入使用的产品出来,像tableau一样有着强大的自助分析功能。当我问到,Canary和tableau差在哪里时,我并没有得到答案*。其实差在哪里我内心是清楚的,但是是从技术的角度、从理论的角度:二者的OLAP计算方式不同、图形语法的设计不同、对于不同输入的计算视图也不同。至于数据库连接,数据清洗等当然也是,但这部分可以不作为tableau的主要模块来讨论。我最终希望得到的答案,是从一个真正的使用者的角度,告诉我Canary差在哪里,应该怎么改进

年初的时候在看Wilkinson的The Grammar of Graphics,整个人有点重心偏移,希望Canary的设计是完全的图形语法的交互界面实现。后来冷静下来才意识到,无论做什么,底层使用什么技术,最终都是要辅助数据分析的,辅助业务人员理解数据的。图形语法的理念采用多少、交互上怎么权衡,都是要结合使用者在真实场景下的分析操作来实现的。

举例而言,Canary在实际数据集的测试时遇到过两个主要问题,一个是维度成员数过多带来的分面爆炸,一个是维度数过多带来的选取困难。

Read more
星河开发经历阶段性总结

前一段在配合星河的迭代,稍稍总结一下收货与问题吧。

从接手陌生代码的能力上有所增强,能够比较熟练理清陌生代码的逻辑。出现问题基本能够百分百确定问题产生的原因,而不再像以前一样归结于各种玄学元素。

开发周期上虽然没有出现问题,但从项目整体角度而言还可以进而优化。

Read more
离别

7.5mg * 9 佐匹克林,缺少具体医学数据,但9片的话肯定会有比较强效的。
想着剧情应该是吃到第一个的时候就会颤抖,结果用不了一会9颗全吃.

如果我静默了(,没上班),请帮我收一下尸体,杭后叠彩园2-1-403。房间很乱抱歉。
把实体保存好,只会我爸妈看到我的最后一眼是能夸一句我女儿真漂亮
请不要脱下我的 裙子,我希望能以这个样子离开世界。
这个死前的等待挺有意思的,算是命运给的最好的offer了。

数盒希望能结合一些顶尖学数据的论文来搞,团队里要加入数据分析人员。仅仅是把canary集成进数盒就可以碾压大部分集团可视化产品了。

个人财团的分配主要啊ji’zhong’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d’d

要是挂了就麻烦,数盒一些设计的一线想法和理念主要在一个黑色的笔记本和一个白色变的

也可以去我知乎余缺看依稀文章。

脑子不好使了,有人见到我失联记得联系110,帮我尽快处理一下实体,我可不想烂掉。。。

精神状态混轮导致搜写的无哦也不清楚,总之我明天要是消失的时候帮我收一下尸。


精神状态

最近精神状态真的糟糕到了极点。

没有那么畏惧死亡了。尝试一下也无所谓。

精神负荷太大了,太痛苦了。根本不知道为什么。总是莫名的哭。

整个精神都被抑制了,什么都打不起兴趣。很容易进入焦虑与难过的状态,但说不清为什么。会有一定的刺激源,但刺激源也太普遍了吧,根本无法规避。

不知道该做些什么分散一下注意力,绳子的确是一种方法,但只是短暂性的分散。我想尝试一下更危险一点的方法,写小说或画绘本之类的,这样能直面内心的痛苦把心境表现出来,但是会面对过强的精神刺激,不知道能不能扛得住。


【读书笔记】The Grammar of Graphics - 8. Geometry

8. 几何对象Geometry

Grometric graphs are not visible. As Bertin(1967, 1977) points out, visible elements have features not present in their geometric counterparts.

图形语法中的graph的概念是一个相对抽象的数学概念,其并不对应任何可见的图形,可见的图形是在graph的基础上关联视觉元素(颜色、大小等信息)。

Graph != Physical Representation

对图形分类的方法

  1. appearance under standard aesthetic functions(反例,line != path,但视觉表现相同)
  2. classify them by their geimetric dimensionality
  3. organize them by thier data methods

文章最后采用了根据数据和几何特征来划分几何对象,原因是本文讨论的是基于统计的几何系统,所以要

based on how graphs function in representing statistical data geometrically.

  • Functions 映射数据
  • Partitions 类似于一种分组操作(拆分成子集)
  • networks 连接操作,如line()
Functions Partitions Networks
point
line
area
interval
path
schema
polygon
contour
edge
Read more
【读书笔记】The Grammar of Graphics - 6. Scales

6.标度(scales)

标度理论

标度分为四类:

  • nominal: 1对1映射,unique identifier
  • ordinal: relative ranks
  • interval: difference is comparable
  • ratio: count?

对于标度的运算,往往需要更为详细的信息,比如我们在blend操作时会进行定义域检查(如关系型数据库的并操作)

货币维度是一个依赖于时间的维度,这是由于货币本身会膨胀或紧缩。在计算时要考虑通胀率。

  • 基本度量(elemental measurement / primary unit)
  • 衍生度量(derived measurement / secondary unit)

标度0并不一定意味着0或无,如温度为0。

标度与图形的关系
关于0标度的定义是对标度的描述而非对图形的描述:
例如,对bars进行描述时我们关心的是起始位置和终止位置。0点的位置只是用来描述渲染的区域而不是图形本身的性质,图形本身的性质是不受标度的影响的。

Read more
盒马数据产品反思

首先吐槽算法可视化项目,其本质上就是一种传统的cube的可视化类型;唯一不同的是一颗可展开互动的树结构。树会包含预警展示信息(理论上是森林结构)。

产品的开发链路为 产品->(交互)->UI->研发。这个开发链路是盒马惯用的开发模式,但是由于盒马的交互/UI风格非常传统保守,且极度匮乏数据产品的知识,基本上在设计产品时采用在图表库中查找能用的图标来强行套用。很多图标对数据的展示能力极度匮乏。与此同时,基于图表的思考方式会极大程度降低分析人员对数据与图形的理解能力(这一点在GoG中有提到)。也导致G2本身的价值完全丧失,也就是集团消耗高成本投资的新式图形系统资产完全被浪费掉,同时会使得底层开发人员对G2本身产生极大的质疑,在技术选型上内心甚至会更倾向于echarts。

数据产品,在进入研发前,必须由数据分析/数据可视化(来自通用式BI/GS一线研发团队)的专业人员进行产品原型的设计。这一环节也是反馈到集团图形系统研究的重要环节,帮助构建图形系统的开发理论与方法。

非可视化开发专业人员在进行数据可视化时,往往缺乏对任意数据情况下的可视化效果的思考。对于数据特性(数据量、特征值、维度、度量、层级结构)发生变化时不能给出可视化自动切换或检测的边界条件。使得可视化产出是“死”的,不够灵活。对于什么原因会导致可视化性能降低、如何避免此问题完全不知,所以在可视化设计这一环节,必须交由专业的可视化开发人员进行。否则团队永远难以积累可视化开发经验,只是在自己的安逸区开发着马马虎虎可以应付交差的产品。

另外,数盒竟无法支持这样一个产品,而需要专门配置开发人员,为何不反思数盒在此的局限性?这也是数盒团队中缺少一个专业的可视化leader来持续跟进优化产品,单纯只是对一些用户提出的必须解决的需求逐个解决,不思考其中的共同性,不去总结,不去反思。那么这个产品又死掉了。

数盒究竟能否成员盒马内部可视化团队中的可视化开发人员的原型开发工具,tableau是否可以,数盒与tableau在原型产品开发上的区别在哪里,各自的优势劣势在哪里?

当然,一味的抱怨是没有用的,这里对目前来说更为有价值的反思是自身如何对当前环境做出决策。首先,研究数盒目前内部有价值的部分,结合盒马的业务做出客观的分析。然后看哪些优势是可以集成到canary中的。思考如何设计GoG的图形系统,开发GoG目前所遇到的局限性在哪里,有哪些部分是G2导致的,哪些不是,其他可视化库能否解决该问题,不能的话,是为什么,自己手动解决该问题的难度评估。

另外,在这样的环境中,如何尽力影响团队。在当前体制下,这种影响会受到哪些阻碍,有什么方法减小这些阻碍的影响。


项目开发思考

注意组件大小

确认组件的智能拆分足够足够细致,智能分配专一。通用组件封装到资产库以便复用。部分组件注意ui和逻辑的解耦。

react虽然没有vue的组件逻辑清晰,但是可以参考vue组件的结构来编写react组件:

  • 拆分methods, computed(目前还没有集中管理好方案,建议暂时均以getter的方式直接注册在当前组件中)
  • 简化表单场景,统一由一个函数负责设置setState,毕竟组件内事件没有像redux那种监控溯因机制。
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    constructor (props) {
    super(props);
    for (let method in this.methods) {
    console.log(method)
    this[method] = this.methods[method];
    }
    }
    methods = {
    testThis: () => {
    console.log(this.state)
    },
    testFunc () {
    console.log(this.state)
    }
    }
    render () {
    this.methods.testThis() // state
    this.methods.testFunc() // undefined
    this.testThis() // state
    this.testFunc() // state
    }
Read more

我人生目前三次重大错误决策:

  • 13年OI省选,逃避,没有全力以赴
  • 15年高考,逃避;也没有选择复读
  • 18年申请季,逃避

想死,人生走到我这个状态,真的已经烂到透了。