Windows 10版本布局,初级介绍,老鸟绕行!

会员讨论Win1K Published the article • 3 comments • 141 views • 2016-07-23 19:10 • 来自相关话题

Windows 10是微软历史上第一个用户与开发人员合力完成的操作系统,这导致很多原本用户不需要了解的名词出现在我们面前。此次就当抛砖引玉,和大家聊聊那些看上去专业的名词是什么意思。

自从微软于2014年秋季发布会上正式公布了Windows 10之后,正式宣布了毁誉参半的Windows 8/8.1的一页已经揭去,而微软将数字从8直接升至10,不仅意味着功能上的大步伐跃进,也意味着相比之前封闭式的内部测试,Windows 10是微软第一次尝试将操作系统的开发任务部分交予用户,让用户参与进来。虽然这在开放与交流上是一次不可多得的尝试,但也是第一次将诸多专业词汇推至用户面前:通道、分支 (Branch)、预览、Ring,等等。故本文仅在于扫盲,向刚刚接触Windows 10的用户简单介绍一下细节,老鸟请移步Feedback Hub。





英雄的一生,注定坎坷而传奇、充满未知

 
正式版推送的前夕:Insider Program

首先让我们随着时间的脉络理清Windows 10的发展,在2014年9月微软第一次公开展示了Windows 10的面貌,当时还在内部测试阶段的Windows 10全名为Windows 10 Technical Preview,也就是技术预览版。对于公众来说,这是最初级,完成度最低的版本。我们知道Windows 8.1 Update的Build编号停留在9600,第一个公开展示的Windows 10延续了下去,Build版本为9841,这也是第一个对外推送预览的Windows 10版本。
 
这里我们要聊聊第一个名词:Ring,Ring这个词没有官方的中文译法,它的含义是指预览计划(Insider Program)中根据推送速度和稳定程度划分用户频道的一个单位。初期的Insider Program只有两个方向:快速通道(Fast Ring)以及慢速通道(Slow Ring)。事实上Insider Program前任负责人Gabe Aul也承认,开发效率爆炸的微软其实每天都在完成至少一个Build(Daily Build),完成之后他们会部署至OSG(Operating System Group)接受Debug和性能测试,如果表现达到了对外公开发布的程度,它就会推送至Fast Ring用户,如果Fast Ring用户反响不错的话,它就有可能被推送至Slow Ring用户。





一个个Build就是如此传世下去

2014年对于Windows 10来说是短暂的一年,开放用户仅仅面向狂热的技术预览爱好者,在当年最后一个Build 9879中,出现了大规模硬盘无法被识别的事故,小编就是在这个Build上船的,好在硬盘平安无事,只是输入法无法更换“而已”。
 
随后的Build 2015对于Windows 10是一个重要的日子,在大会闭幕后不久推送的Build 10074上,技术预览版(Technical Preview)终于化身为完成度更高的内部预览版(Insider Preview),这意味这通向RTM(Release To Manufacturing)的重要一步。

版本与版本的归属:分支(Branch)

终于,在去年的7月29日,微软开始推送正式版本Windows 10 Build 10240,属于Threshold 1。对于普通公众来说,这一天开始他们第一次接触了Windows 10。 虽然在升级时有很多用户反映接受更新推送的可靠性远远不如下载镜像刻录至USB介质的安装,但是这一天对于微软和Windows 10还是十分有意义的一天。





 
这里我们可以说说第二个概念:分支(Branch)。由于Windows 10的开发工作分为诸多板块,海量的工作计划无法在短时间内完成,所以WDG(Windows Development Group)设置了多个分支,每个分支中有各自的开发任务。在一共的四个分支中,首先来说说Insider Preview Branch,这个分支包含的是目前正在开发中的Build,也就是交予Insider用户预览的版本。那么无论是Fast Ring还是Slow Ring都属于预览版本(Preview Build),也都属于这个分支。 









 
而等到一个4-7个月的开发周期结束之后,微软会放出一个稳定的RTM版本,作为开发历程的总结。这段时间内(一个RTM到下一个RTM之间)一般会确立一个开发代号,比如我们熟悉的Threshold和RedStone,以此区分不同的开发阶段,比如自2015年7月29日至今年的8月2日都属于Threshold部分,接收了年度更新之后Windows 10对于普通用户就进入了RedStone。

那么在这些姑且可以称之为“正式版”的Build之上会通过一连串的累计更新来满足普通用户的需求,这时从分支上已经脱离Preview Branch,进入Current Branch,这个分支包括该RTM版本以及所有累积更新版本。





 
按照微软的规划,Windows 10的部署可以分为Insider Preview Branch、Current Branch、Current Branch for Bussiness,以及Long Term Servicing Branch。可以简称为IPB、CB、CBB、LTSB。对于后者LTSB大家可以忽略,记住前三者即可,不过需要大家参考的是不同的Branch对应不同的服务期限,CB对应的是4个月,CBB对应8个月,而LTSB对应10年。大家可能注意到了,4个月大致是Windows 10完成一个RTM版本的间隙,也就是Current Branch,对应4个月的RTM版本大家可以理解为Windows 10 Update 1,而支持8个月的Current Branch for Business可以大致理解为Windows 10.1,虽然意义有不同,但是只要看成是一段开发进度中最为稳定的一个版本即可,所有的累计更新都是基于此上。





 
最稳定但是功能最少的版本:RTM和累积更新(Culumative Update)

而说到累计更新(Cumulative Update),其实就是面对没有参加Insider Program的普通用户、基于RTM版本之上为了提高性能、修复错误而一直发布的更新补丁,也就是每个月收到推送的稳定性更新, 时间上类似于Win7/8/8.1在每个月补丁日收到更新一样,因此也常称之为“月份+累计更新”。比如在微软的官方支持页面中,使用的表述就是“July Cumulative Update(七月累计更新)”。累计更新是最稳定、同时是最保守的版本,本身不包括任何新功能,仅仅面对基础性的性能更新。





Threshold 2,基于Build 10586(ver.1511)的累积更新历史
 
在RTM版本和累积更新的命名上还可以详细说说,RTM版本身也是一个Build,所以也有他们的版本号(Build 10240、10586),但是和预览版本不一样的是,为了方便更多的用户的记忆和书写,还可以表达为“年份+月份”,譬如“ver.1507(10240)、1511(10586)、1607(14393?)”。而累积更新其实就是补丁(KBxxxxx)的集合,在安装之后便有了次要版本号(10586.xxx)。





Threshold 1,基于Build 10240(ver.1507)的累积更新历史

以2015年7月第一次正式推送的Build 10240为例,大版本号为Ver.1507,属于Threshold 1,在版本号中写作th_1。自2015年11月和Build 10586共存,后者大版本号为Ver.1511,分支为Threshold 2,版本号写作th_2。对于这两个版本,无论是称之为Build 10240、10586,还是1507、1511都没有错,因为他们都是Current Branch分支。

读到这里大家就应该可以分清,如果看到是的诸如10240.xxxx,10586.xxxx,那就是曾经的RTM版本之后的累计更新。而如果看到不规律且变化多端的Build,比如最近的14383、14385、14388、14390、14393,这些就是在开发最前沿的Fast Ring Build或Slow Ring Build,他们快的每周有三次更新,慢的两周也会更新一次。需要提醒大家的是,在进入RedStone分支后,预览更新的稳定性已经有了明显好转,作为日常主力工作机已经不用担心太多。
这里要特别强调一下,平时是经常有用户或询问、或抱怨微软的正式版到底要等多久,为什么总是测试版刷存在感。其实去年微软已经推送了正式版,就是Build 10240,在那之后的全部是正式版,有区分的仅仅在于是否是预览人员。
 
从Threshold到RedStone、再到?

在TH1中(7月-11月),平心而论Windows 10的可靠性并不好,所以微软优先解决的是开始菜单、Microsoft Edge浏览器、磁盘性能、Cortana等基础性功能的可靠性修复,尽可能满足正常的工作任务。后来的的TH2分支中,优先任务为Cortana变得更强大、更加跨平台、更加无所不能,Windows Ink更加随心所欲,Microsoft Edge浏览器加入插件支持、UWP解锁帧率等进一步的功能强化。而在未来的RedStone中,Windows 10会变得更加跨平台、更加智慧、UI更加绚丽。

微软自2015年的11月12日推送了Build 10586之后,第二道分水岭来临。对于普通用户,他们从Threshold 1分支迁至Threshold 2分支。对于Inider Program来说,已经在心头缭绕已久的RedStone 1即将来临。这时微软做了两件事:第一件,在Fast Ring、Slow Ring之后增加了第三项通道:Release Preview Ring,在Slow Ring和RTM之间为风险和新鲜感添加了一副新的天平,因为虽然Release Preview在时间上可以提前收到更新版本,但是在分支上已经属于Current Branch。第二件就是将《Windows预览计划》App集成至系统设置内部,成为系统功能的一部分。如果说还有一件的话,就是将《会员中心》App和《Feedback》App合为一款《Feedback Hub》App,方便用户添加反馈。





 
在8月2日,微软会推送RedStone 1分支的正式版,版本号目前暂不清楚(据传是Build 14393),但是大版本号为1608应该是跑不了的。该版本会继承所有自去年11月至目前的开发成果,并在接下来的数月中接受累计更新。虽然Threshold只有两个编号,但是根据目前的传言,RedStone将 包括出现三次更新,RedStone 2目前已经跳票至明年春季,而RedStone 3最少也是秋季。此前微软已经宣布Windows 10作为一种服务将会使公司最后一部操作系统,未来Windows 10的道路将蔓延至何处,我们拭目以待。





Windows 10概念设计方案之一,Metro UI是最亮眼的设计
 
 
转载自超能网,作者:Axe斧娃 查看全部


Windows 10是微软历史上第一个用户与开发人员合力完成的操作系统,这导致很多原本用户不需要了解的名词出现在我们面前。此次就当抛砖引玉,和大家聊聊那些看上去专业的名词是什么意思。


自从微软于2014年秋季发布会上正式公布了Windows 10之后,正式宣布了毁誉参半的Windows 8/8.1的一页已经揭去,而微软将数字从8直接升至10,不仅意味着功能上的大步伐跃进,也意味着相比之前封闭式的内部测试,Windows 10是微软第一次尝试将操作系统的开发任务部分交予用户,让用户参与进来。虽然这在开放与交流上是一次不可多得的尝试,但也是第一次将诸多专业词汇推至用户面前:通道、分支 (Branch)、预览、Ring,等等。故本文仅在于扫盲,向刚刚接触Windows 10的用户简单介绍一下细节,老鸟请移步Feedback Hub。

Kurz-vor-dem-Windows-10-Release-zeigen-die-PC-Absaetze-weiter-steil-nach-unten-.jpg

英雄的一生,注定坎坷而传奇、充满未知


 
正式版推送的前夕:Insider Program

首先让我们随着时间的脉络理清Windows 10的发展,在2014年9月微软第一次公开展示了Windows 10的面貌,当时还在内部测试阶段的Windows 10全名为Windows 10 Technical Preview,也就是技术预览版。对于公众来说,这是最初级,完成度最低的版本。我们知道Windows 8.1 Update的Build编号停留在9600,第一个公开展示的Windows 10延续了下去,Build版本为9841,这也是第一个对外推送预览的Windows 10版本。
 
这里我们要聊聊第一个名词:Ring,Ring这个词没有官方的中文译法,它的含义是指预览计划(Insider Program)中根据推送速度和稳定程度划分用户频道的一个单位。初期的Insider Program只有两个方向:快速通道(Fast Ring)以及慢速通道(Slow Ring)。事实上Insider Program前任负责人Gabe Aul也承认,开发效率爆炸的微软其实每天都在完成至少一个Build(Daily Build),完成之后他们会部署至OSG(Operating System Group)接受Debug和性能测试,如果表现达到了对外公开发布的程度,它就会推送至Fast Ring用户,如果Fast Ring用户反响不错的话,它就有可能被推送至Slow Ring用户。

windows_10_release_rings.jpg

一个个Build就是如此传世下去

2014年对于Windows 10来说是短暂的一年,开放用户仅仅面向狂热的技术预览爱好者,在当年最后一个Build 9879中,出现了大规模硬盘无法被识别的事故,小编就是在这个Build上船的,好在硬盘平安无事,只是输入法无法更换“而已”。
 
随后的Build 2015对于Windows 10是一个重要的日子,在大会闭幕后不久推送的Build 10074上,技术预览版(Technical Preview)终于化身为完成度更高的内部预览版(Insider Preview),这意味这通向RTM(Release To Manufacturing)的重要一步。

版本与版本的归属:分支(Branch)

终于,在去年的7月29日,微软开始推送正式版本Windows 10 Build 10240,属于Threshold 1。对于普通公众来说,这一天开始他们第一次接触了Windows 10。 虽然在升级时有很多用户反映接受更新推送的可靠性远远不如下载镜像刻录至USB介质的安装,但是这一天对于微软和Windows 10还是十分有意义的一天。

20160719143949.png

 
这里我们可以说说第二个概念:分支(Branch)。由于Windows 10的开发工作分为诸多板块,海量的工作计划无法在短时间内完成,所以WDG(Windows Development Group)设置了多个分支,每个分支中有各自的开发任务。在一共的四个分支中,首先来说说Insider Preview Branch,这个分支包含的是目前正在开发中的Build,也就是交予Insider用户预览的版本。那么无论是Fast Ring还是Slow Ring都属于预览版本(Preview Build),也都属于这个分支。 

20160719144020.png

win10testing.jpg

 
而等到一个4-7个月的开发周期结束之后,微软会放出一个稳定的RTM版本,作为开发历程的总结。这段时间内(一个RTM到下一个RTM之间)一般会确立一个开发代号,比如我们熟悉的Threshold和RedStone,以此区分不同的开发阶段,比如自2015年7月29日至今年的8月2日都属于Threshold部分,接收了年度更新之后Windows 10对于普通用户就进入了RedStone。

那么在这些姑且可以称之为“正式版”的Build之上会通过一连串的累计更新来满足普通用户的需求,这时从分支上已经脱离Preview Branch,进入Current Branch,这个分支包括该RTM版本以及所有累积更新版本。

20160719145831.png

 
按照微软的规划,Windows 10的部署可以分为Insider Preview Branch、Current Branch、Current Branch for Bussiness,以及Long Term Servicing Branch。可以简称为IPB、CB、CBB、LTSB。对于后者LTSB大家可以忽略,记住前三者即可,不过需要大家参考的是不同的Branch对应不同的服务期限,CB对应的是4个月,CBB对应8个月,而LTSB对应10年。大家可能注意到了,4个月大致是Windows 10完成一个RTM版本的间隙,也就是Current Branch,对应4个月的RTM版本大家可以理解为Windows 10 Update 1,而支持8个月的Current Branch for Business可以大致理解为Windows 10.1,虽然意义有不同,但是只要看成是一段开发进度中最为稳定的一个版本即可,所有的累计更新都是基于此上。

20160719144818.png

 
最稳定但是功能最少的版本:RTM和累积更新(Culumative Update)

而说到累计更新(Cumulative Update),其实就是面对没有参加Insider Program的普通用户、基于RTM版本之上为了提高性能、修复错误而一直发布的更新补丁,也就是每个月收到推送的稳定性更新, 时间上类似于Win7/8/8.1在每个月补丁日收到更新一样,因此也常称之为“月份+累计更新”。比如在微软的官方支持页面中,使用的表述就是“July Cumulative Update(七月累计更新)”。累计更新是最稳定、同时是最保守的版本,本身不包括任何新功能,仅仅面对基础性的性能更新。

20160719151429.png

Threshold 2,基于Build 10586(ver.1511)的累积更新历史
 
在RTM版本和累积更新的命名上还可以详细说说,RTM版本身也是一个Build,所以也有他们的版本号(Build 10240、10586),但是和预览版本不一样的是,为了方便更多的用户的记忆和书写,还可以表达为“年份+月份”,譬如“ver.1507(10240)、1511(10586)、1607(14393?)”。而累积更新其实就是补丁(KBxxxxx)的集合,在安装之后便有了次要版本号(10586.xxx)。

20160719151602.png

Threshold 1,基于Build 10240(ver.1507)的累积更新历史

以2015年7月第一次正式推送的Build 10240为例,大版本号为Ver.1507,属于Threshold 1,在版本号中写作th_1。自2015年11月和Build 10586共存,后者大版本号为Ver.1511,分支为Threshold 2,版本号写作th_2。对于这两个版本,无论是称之为Build 10240、10586,还是1507、1511都没有错,因为他们都是Current Branch分支。

读到这里大家就应该可以分清,如果看到是的诸如10240.xxxx,10586.xxxx,那就是曾经的RTM版本之后的累计更新。而如果看到不规律且变化多端的Build,比如最近的14383、14385、14388、14390、14393,这些就是在开发最前沿的Fast Ring Build或Slow Ring Build,他们快的每周有三次更新,慢的两周也会更新一次。需要提醒大家的是,在进入RedStone分支后,预览更新的稳定性已经有了明显好转,作为日常主力工作机已经不用担心太多。
这里要特别强调一下,平时是经常有用户或询问、或抱怨微软的正式版到底要等多久,为什么总是测试版刷存在感。其实去年微软已经推送了正式版,就是Build 10240,在那之后的全部是正式版,有区分的仅仅在于是否是预览人员。
 
从Threshold到RedStone、再到?

在TH1中(7月-11月),平心而论Windows 10的可靠性并不好,所以微软优先解决的是开始菜单、Microsoft Edge浏览器、磁盘性能、Cortana等基础性功能的可靠性修复,尽可能满足正常的工作任务。后来的的TH2分支中,优先任务为Cortana变得更强大、更加跨平台、更加无所不能,Windows Ink更加随心所欲,Microsoft Edge浏览器加入插件支持、UWP解锁帧率等进一步的功能强化。而在未来的RedStone中,Windows 10会变得更加跨平台、更加智慧、UI更加绚丽。

微软自2015年的11月12日推送了Build 10586之后,第二道分水岭来临。对于普通用户,他们从Threshold 1分支迁至Threshold 2分支。对于Inider Program来说,已经在心头缭绕已久的RedStone 1即将来临。这时微软做了两件事:第一件,在Fast Ring、Slow Ring之后增加了第三项通道:Release Preview Ring,在Slow Ring和RTM之间为风险和新鲜感添加了一副新的天平,因为虽然Release Preview在时间上可以提前收到更新版本,但是在分支上已经属于Current Branch。第二件就是将《Windows预览计划》App集成至系统设置内部,成为系统功能的一部分。如果说还有一件的话,就是将《会员中心》App和《Feedback》App合为一款《Feedback Hub》App,方便用户添加反馈。

wp_ss_20160716_0001.png

 
在8月2日,微软会推送RedStone 1分支的正式版,版本号目前暂不清楚(据传是Build 14393),但是大版本号为1608应该是跑不了的。该版本会继承所有自去年11月至目前的开发成果,并在接下来的数月中接受累计更新。虽然Threshold只有两个编号,但是根据目前的传言,RedStone将 包括出现三次更新,RedStone 2目前已经跳票至明年春季,而RedStone 3最少也是秋季。此前微软已经宣布Windows 10作为一种服务将会使公司最后一部操作系统,未来Windows 10的道路将蔓延至何处,我们拭目以待。

Immagine-800x450.jpg

Windows 10概念设计方案之一,Metro UI是最亮眼的设计
 
 
转载自超能网,作者:Axe斧娃

Windows 10应用设计加速器--设计语言的变迁

UWP Nokiss Published the article • 0 comments • 86 views • 2016-06-04 18:23 • 来自相关话题

从Windows 8到Windows 10,微软经历了重大的商业变革,与此同时也带来了设计上翻天覆地的变化。接下来的4期内容,将深入浅出的为大家讲解微软设计语言的变迁历程;对于那些正在规划,或者已经着手进行Windows 10应用设计的朋友,也将通过这几期内容对于通用应用有更深入、更直观的了解。

从Windows Phone7开始,微软就提出了非常先进的移动端设计理念,但一方面由于理念过于激进难以落地,一方面受限于硬件设备的更新与普及程度,另一方面也受限于微软在移动领域里有限的市场规模,导致这套设计理念很难被绝大多数用户接受。

长久以来,微软一直处于 PC 领域的霸主地位,众多系统版本中,市场份额占据最多的是 Windows 7。在全新的 Windows 10 平台中,微软融合了 Windows 7 以及 Windows 8 的优势,进行设计优化、重新包装,交还到用户手中。不管是习惯用传统桌面端操作的XP、Windows 7 老用户,还是已经习惯 Windows 8 的新用户,都可以通过开始菜单,使用自己熟悉的操作方式,快速上手。
 
设计原则的发展 

微软是首家提出移动端应用扁平化设计理念的公司。这套设计风格最初被称为Metro Design Language(现已更名,视觉风格上也有所改变),最早来源于瑞士平面设计,不光是平面设计,建筑、时装、书籍排版设计等等各处都能看到这种基于排版设计语言的影子。

在现代化的地铁、机场中的视觉引导系统通常会采用硕大的字体和醒目整齐的色块来吸引人们的注意。这些公共场合的指示牌为微软设计团队提供了灵感,进而把这种全球通用的视觉语言迁移到移动端的应用设计中,为用户提供快速、简洁、直接、明确的设计。也就是我们后来看到的 Windows 8 Metro UI。

2006年著名的 Zune 播放器开始使用类似 MetroUI 的设计风格。微软的设计师计划重新设计现有用户界面、更清爽的排版和较少的重点以便于用户使用。其清爽排版和设计给用户耳目一新的冲击。Metro UI在之后的时间里运用在 Windows、Windows Phone、Office 和 Xbox 甚至微软的硬件产品中。





 
现如今,MetroDesign的设计原则已经延伸遍布到整个Windows 10平台,并且在原来的理论基础上以更开放的心态进行了优化。于是我们看到了正式更名后的Microsoft Design Language:

Keep it simple 保持简单
 
确保一致的简单性,直观的设计不言自明。确保为用户提供的内容简洁高效,易于阅读和理解。

Make it personal 彰显个性

创建与用户的情感连接。针对用户的生活、思考和行动方式进行设计,让用户感觉这是为他量身定做的体验。

Think universal 考虑通用

秉承以人为本的态度,充分考虑用户不同情境下的需求,产出具有包容性的产品与技术。

Create delight 创造愉悦

创造让用户尖叫的体验,关注场景化的感知。
 
图  标 
 
当我们打开 Windows10 资源管理器,会发现界面上的图标、按钮,都进行了重新设计,在扁平化的基础上采用极简风格。

下图是 Windows 8 时代的指令按钮,这简直是 Windows 8 时代平台视觉样式的典型代表。这种样式的优势在于能够凸显微软平台设计的独特,但与此同也因为设计风格与其他平台格格不入而带来设计门槛过高,难以进行设计迁移的问题。






而在 Windows 10平台,这样的指令按钮样式已经成为历史,我们会发现系统层级的控件已经全部采用极简的视觉风格,大大减少了 Windows 平台与 iOS, Android 以及 Web 之间的差异,从这一点也可以看到转型中的微软逐渐开放的态度。






Windows 10 系统图标设计规范供大家参考:





在应用交互层面,Windows8时代的应用导航样式比较单一。熟悉Windows移动端产品的朋友一定都记得,不论是手机还是平板,Windows 8都是以独特的“动态导航”和相对单一的“横向滑动”浏览模式著称。这种高度统一的交互模式,在一定程度上限制了设计师的创造力,对于不同产品的品牌塑造也带来一些束缚。

在Windows 10平台,我们看到了更丰富的布局和控件样式,在原Windows 8的基础上进行了很大程度的优化。新的应用布局及结构会在后面几期内容中陆续跟大家见面。





 
Scaling, Responsive, Adaptive 

图中所展示了 Windows 设备家族。从无屏幕或屏幕在3寸左右大小的可穿戴设备、手机、手机平板、平板、PC、电视、XBOX、Surface Hub,甚至是全息眼镜 HoloLens,同一个 Windows 10应用即将运行在任意 Windows 家族设备上,也就是我们所说的 Universal Windows Platform,通用应用平台。

微软本身拥有很强大的 OEM 厂商群体,在丰富了设备类型的同时,也带来分辨率、屏幕比例花样百出的现状。从跨度超大的应用画布尺寸到多维的自然人机交互方式,对于设计师来说,Windows 10 将是一个机遇与挑战并存的平台。我们要考虑设备的多样性,如何尽可能复用设计图去兼顾不同的设备,并且做好适配工作;如何响应传统桌面端与平板模式的切换;当应用视窗尺寸发生变化的时候,如何调整界面布局,等等。





 
在解答这些问题之前,首先来解读“等比缩放(Scaling)”、“响应式设计(Responsive Design)”、“自适应设计(Adaptive Design)”这三个概念在Windows 10应用设计中的意义,以便通过它们来指导我们进行跨设备多场景的应用设计。
 
等比缩放:WindowsPhone 上传统的适配手段。在应用跨越的设备物理尺寸范围比较小的时候,比如只是基于4寸到5寸的手机,可以通过直接等比放大或者缩小界面元素来完成适配。但当一款应用要跨越手机直到PC这类大显示器的时候,简单的内容缩放显然会降低信息的可读性,并不能适应用户在大设备上的阅读习惯。因此,在 Windows 10 平台,我们会更多的听到响应式、适应式设计的概念。

响应式:简单的说,它来源于能够自动识别屏幕宽度、并做出相应调整的网页设计。会随着显示尺寸的变化,时时调整内容区域的展现效果,强调的重点在于视觉体验。在 Windwos10 平台上,通用应用以大家熟悉的视窗形式进行展现,伴随用户手指拖拽所触发的视窗尺寸变化,界面布局发生视觉层面的变化,以确保在任何情况下,内容都可以正常展示。

这种基于视窗的展现形式是大家在传统 Win32 应用或者网页浏览中早就习以为常的。同网页设计一样,我们建议设计师采用百分比进行页面内容的划分而非绝对像素值,从而最大程度确保不同视窗下的内容展现都完美。前端设计师或者开发者可以很方便的使用 Windows 10 控件 Relative Panel 配合 Visual State Manager(视觉状态管理器)实现响应式设计布局。可以把 RelativePanel 比喻成一个大容器,用来承载各种UI元素,通过 VisualState Manager 控制这个容器内的元素布局发生变化。





 
注意以下几个概念:
 
VisualState 指的是界面的某种状态,里面包含两个属性,即 Triggers 和 Setters。Triggers 是 Visual State 的触发条件,可以设置当某个触发条件成立的时候,将 Setters 相应的属性值应用到控件的相应属性上。系统自带的 Triggers 包括界面显示宽度、设备类型。同时也支持开发者对 Triggers 进行自定义,当满足了相应的触发机制,系统会自动调起相应的 UI。Setters 包含了控件的属性以及相应设置值,当 Triggers 条件成立,相应的 Setters 属性值生效,应用到相应控件的相应的属性上。

基于这个方式,我们可以轻松实现不同视窗宽度下,UI 元素之间的布局变化。例如下图中的大麦 APP,仅通过一套前端 XAML 控件实现了从小屏幕的手机到大屏幕 PC 的适配。





 
3个 Tips 给大家参考:
 
缩放:内容配合所在容器或者显示宽度的大小变化,而被积压或拉伸进行自动调整。





 
流动:所在容器或者显示宽度大小发生变化,但内容本身不发生大小变化,而是往容器的下方延展显示。 





 
位移:相对位置的改变。 
 




 
自适应:在设备越来越丰富的今天,另外一个重要概念就是“自适应”。它是基于设备适配、跨平台设计而产生的理念。因此,自适应设计强调的不只是单纯的视觉布局变化,更多的是需要应用具备适应不同硬件设备的能力。基于不同设备,用户会有差异化的功能需求,不同硬件本身的能力也存在差异。

例如我们现在看到的稀奇艺术,这是 Windows 10 平台一款基于 AR 技术的、跨手机和平板设备的艺术类 APP。首页的雕像展示,平板设备上采用了带有纵深的3D效果;考虑到手机硬件性能有限,于是在雕像展示上则采用了横向滑动的卡片效果。
 





平板展示效果




手机展示效果
 
3个Tips给大家参考:
变革:基于不同设备,不同的用户使用场景,在功能上有所颠覆。





重构:由于手机端显示空间有限,平板端一屏内展现的内容,在手机端被拆分成上下级关系,带来应用信息框架的改变。





替代:用户在不同设备上差异化的使用习惯,有可能带来差异化的应用结构和控件使用。
 





在下期内容中,会为大家讲解从 Windows8 到 Windows 10,微软移动端应用的结构变化,以及全新 Windows10 控件使用技巧。会有更多设计资源带给大家哦~

如果您也对 Windows10 平台产品设计感兴趣,或者正纠结于设计或开发的难题,欢迎发邮件到 waa@Microsoft.com联系WAA团队,我们期待您的反馈。
 
 
转载自 软中国MSDN公众号,无删减。 查看全部
从Windows 8到Windows 10,微软经历了重大的商业变革,与此同时也带来了设计上翻天覆地的变化。接下来的4期内容,将深入浅出的为大家讲解微软设计语言的变迁历程;对于那些正在规划,或者已经着手进行Windows 10应用设计的朋友,也将通过这几期内容对于通用应用有更深入、更直观的了解。

从Windows Phone7开始,微软就提出了非常先进的移动端设计理念,但一方面由于理念过于激进难以落地,一方面受限于硬件设备的更新与普及程度,另一方面也受限于微软在移动领域里有限的市场规模,导致这套设计理念很难被绝大多数用户接受。

长久以来,微软一直处于 PC 领域的霸主地位,众多系统版本中,市场份额占据最多的是 Windows 7。在全新的 Windows 10 平台中,微软融合了 Windows 7 以及 Windows 8 的优势,进行设计优化、重新包装,交还到用户手中。不管是习惯用传统桌面端操作的XP、Windows 7 老用户,还是已经习惯 Windows 8 的新用户,都可以通过开始菜单,使用自己熟悉的操作方式,快速上手。
 
  • 设计原则的发展 


微软是首家提出移动端应用扁平化设计理念的公司。这套设计风格最初被称为Metro Design Language(现已更名,视觉风格上也有所改变),最早来源于瑞士平面设计,不光是平面设计,建筑、时装、书籍排版设计等等各处都能看到这种基于排版设计语言的影子。

在现代化的地铁、机场中的视觉引导系统通常会采用硕大的字体和醒目整齐的色块来吸引人们的注意。这些公共场合的指示牌为微软设计团队提供了灵感,进而把这种全球通用的视觉语言迁移到移动端的应用设计中,为用户提供快速、简洁、直接、明确的设计。也就是我们后来看到的 Windows 8 Metro UI。

2006年著名的 Zune 播放器开始使用类似 MetroUI 的设计风格。微软的设计师计划重新设计现有用户界面、更清爽的排版和较少的重点以便于用户使用。其清爽排版和设计给用户耳目一新的冲击。Metro UI在之后的时间里运用在 Windows、Windows Phone、Office 和 Xbox 甚至微软的硬件产品中。

640.jpg

 
现如今,MetroDesign的设计原则已经延伸遍布到整个Windows 10平台,并且在原来的理论基础上以更开放的心态进行了优化。于是我们看到了正式更名后的Microsoft Design Language:

Keep it simple 保持简单
 
确保一致的简单性,直观的设计不言自明。确保为用户提供的内容简洁高效,易于阅读和理解。

Make it personal 彰显个性

创建与用户的情感连接。针对用户的生活、思考和行动方式进行设计,让用户感觉这是为他量身定做的体验。

Think universal 考虑通用

秉承以人为本的态度,充分考虑用户不同情境下的需求,产出具有包容性的产品与技术。

Create delight 创造愉悦

创造让用户尖叫的体验,关注场景化的感知。
 
  • 图  标 

 
当我们打开 Windows10 资源管理器,会发现界面上的图标、按钮,都进行了重新设计,在扁平化的基础上采用极简风格。

下图是 Windows 8 时代的指令按钮,这简直是 Windows 8 时代平台视觉样式的典型代表。这种样式的优势在于能够凸显微软平台设计的独特,但与此同也因为设计风格与其他平台格格不入而带来设计门槛过高,难以进行设计迁移的问题。

640.png


而在 Windows 10平台,这样的指令按钮样式已经成为历史,我们会发现系统层级的控件已经全部采用极简的视觉风格,大大减少了 Windows 平台与 iOS, Android 以及 Web 之间的差异,从这一点也可以看到转型中的微软逐渐开放的态度。

64110.png


Windows 10 系统图标设计规范供大家参考:

6402.png

在应用交互层面,Windows8时代的应用导航样式比较单一。熟悉Windows移动端产品的朋友一定都记得,不论是手机还是平板,Windows 8都是以独特的“动态导航”和相对单一的“横向滑动”浏览模式著称。这种高度统一的交互模式,在一定程度上限制了设计师的创造力,对于不同产品的品牌塑造也带来一些束缚。

在Windows 10平台,我们看到了更丰富的布局和控件样式,在原Windows 8的基础上进行了很大程度的优化。新的应用布局及结构会在后面几期内容中陆续跟大家见面。

641110.jpg

 
  • Scaling, Responsive, Adaptive 


图中所展示了 Windows 设备家族。从无屏幕或屏幕在3寸左右大小的可穿戴设备、手机、手机平板、平板、PC、电视、XBOX、Surface Hub,甚至是全息眼镜 HoloLens,同一个 Windows 10应用即将运行在任意 Windows 家族设备上,也就是我们所说的 Universal Windows Platform,通用应用平台。

微软本身拥有很强大的 OEM 厂商群体,在丰富了设备类型的同时,也带来分辨率、屏幕比例花样百出的现状。从跨度超大的应用画布尺寸到多维的自然人机交互方式,对于设计师来说,Windows 10 将是一个机遇与挑战并存的平台。我们要考虑设备的多样性,如何尽可能复用设计图去兼顾不同的设备,并且做好适配工作;如何响应传统桌面端与平板模式的切换;当应用视窗尺寸发生变化的时候,如何调整界面布局,等等。

611140.jpg

 
在解答这些问题之前,首先来解读“等比缩放(Scaling)”、“响应式设计(Responsive Design)”、“自适应设计(Adaptive Design)”这三个概念在Windows 10应用设计中的意义,以便通过它们来指导我们进行跨设备多场景的应用设计。
 
等比缩放:WindowsPhone 上传统的适配手段。在应用跨越的设备物理尺寸范围比较小的时候,比如只是基于4寸到5寸的手机,可以通过直接等比放大或者缩小界面元素来完成适配。但当一款应用要跨越手机直到PC这类大显示器的时候,简单的内容缩放显然会降低信息的可读性,并不能适应用户在大设备上的阅读习惯。因此,在 Windows 10 平台,我们会更多的听到响应式、适应式设计的概念。

响应式:简单的说,它来源于能够自动识别屏幕宽度、并做出相应调整的网页设计。会随着显示尺寸的变化,时时调整内容区域的展现效果,强调的重点在于视觉体验。在 Windwos10 平台上,通用应用以大家熟悉的视窗形式进行展现,伴随用户手指拖拽所触发的视窗尺寸变化,界面布局发生视觉层面的变化,以确保在任何情况下,内容都可以正常展示。

这种基于视窗的展现形式是大家在传统 Win32 应用或者网页浏览中早就习以为常的。同网页设计一样,我们建议设计师采用百分比进行页面内容的划分而非绝对像素值,从而最大程度确保不同视窗下的内容展现都完美。前端设计师或者开发者可以很方便的使用 Windows 10 控件 Relative Panel 配合 Visual State Manager(视觉状态管理器)实现响应式设计布局。可以把 RelativePanel 比喻成一个大容器,用来承载各种UI元素,通过 VisualState Manager 控制这个容器内的元素布局发生变化。

642310.jpg

 
注意以下几个概念:
 
  • VisualState 指的是界面的某种状态,里面包含两个属性,即 Triggers 和 Setters。
  • Triggers 是 Visual State 的触发条件,可以设置当某个触发条件成立的时候,将 Setters 相应的属性值应用到控件的相应属性上。系统自带的 Triggers 包括界面显示宽度、设备类型。同时也支持开发者对 Triggers 进行自定义,当满足了相应的触发机制,系统会自动调起相应的 UI。
  • Setters 包含了控件的属性以及相应设置值,当 Triggers 条件成立,相应的 Setters 属性值生效,应用到相应控件的相应的属性上。


基于这个方式,我们可以轻松实现不同视窗宽度下,UI 元素之间的布局变化。例如下图中的大麦 APP,仅通过一套前端 XAML 控件实现了从小屏幕的手机到大屏幕 PC 的适配。

612140.jpg

 
3个 Tips 给大家参考:
 
  • 缩放:内容配合所在容器或者显示宽度的大小变化,而被积压或拉伸进行自动调整。


640.png

 
  • 流动:所在容器或者显示宽度大小发生变化,但内容本身不发生大小变化,而是往容器的下方延展显示。 


641111110.png

 
  • 位移:相对位置的改变。 

 
611240.png

 
自适应:在设备越来越丰富的今天,另外一个重要概念就是“自适应”。它是基于设备适配、跨平台设计而产生的理念。因此,自适应设计强调的不只是单纯的视觉布局变化,更多的是需要应用具备适应不同硬件设备的能力。基于不同设备,用户会有差异化的功能需求,不同硬件本身的能力也存在差异。

例如我们现在看到的稀奇艺术,这是 Windows 10 平台一款基于 AR 技术的、跨手机和平板设备的艺术类 APP。首页的雕像展示,平板设备上采用了带有纵深的3D效果;考虑到手机硬件性能有限,于是在雕像展示上则采用了横向滑动的卡片效果。
 

平板.jpg

平板展示效果
手机.jpg

手机展示效果
 
3个Tips给大家参考:
  • 变革:基于不同设备,不同的用户使用场景,在功能上有所颠覆。


64qaa0.jpg

  • 重构:由于手机端显示空间有限,平板端一屏内展现的内容,在手机端被拆分成上下级关系,带来应用信息框架的改变。


640.jpg

  • 替代:用户在不同设备上差异化的使用习惯,有可能带来差异化的应用结构和控件使用。

 
633w40.jpg


在下期内容中,会为大家讲解从 Windows8 到 Windows 10,微软移动端应用的结构变化,以及全新 Windows10 控件使用技巧。会有更多设计资源带给大家哦~

如果您也对 Windows10 平台产品设计感兴趣,或者正纠结于设计或开发的难题,欢迎发邮件到 waa@Microsoft.com联系WAA团队,我们期待您的反馈。
 
 
转载自 软中国MSDN公众号,无删减。

    Windows 10 RedStone将带来什么?

    硬件生态Win1K Published the article • 3 comments • 218 views • 2016-03-22 16:42 • 来自相关话题

    微软在本月底召开Build2016大会,本次大会上将会重点公开Win10升级系统RedStone的更新内容,微软称这将让世界疯狂。

    Windows团队高级项目经理里奇·特纳最近更是在Twitter上表示:“体验了Windows 10的新功能,等你们看到的时候会疯掉的。”不过他并没有具体透露都有些什么功能。同时,Azure应用平台及工具开发团队的首席项目经理斯科特·汉森尔曼也表示这些新功能“将改变一切”。





     
    Windows 10 本身还有相当一部分功能不完善,从更新的Insider预览版进展来看,RedStone应该不会让广大Windows 10用户失望,后续更新也一定会继续加强体验,让我们拭目以待吧。

    在这罗列一些可能将在RedStone更新中发布的功能:

    1,资源管理器 File Explorer

    相比其它方面,微软在Windows 10之中对资源管理器(File Explorer)的更改似乎显得比较保守,仍旧维持固有的操作习惯和界面结构。不过据最新消息,微软团队已经确认正在打造资源管理器的一个全面的更新版本,但并未透露具体计划和细节,消息发布者为Windows核心用户体验部门项目经理Peter Skillman,十分可靠。媒体合理地推测该重新设计的资源管理器或将在Windows 10 Redstone重大更新版本中亮相,或带来标签和触控支持。





     
    2,操作中心 Action Center

    操作中心 Action Center)将有更完善的体验,增强可发现性和呈现更多的信息。微软在尝试更大图标的 Action Center 和跳动的通知图标。

    根据最新的预览版14291中Feedback Hub应用显示,微软以Windows 10通知为例展示两种潜在的通知界面,首先两者的通知区域都远离任务栏,主要差别是右下角图标所显示的位置,第一种方案是在通知图标的基础上从右侧滑入应用图标,第二种则是完全替代通知图标。










     
    想要表达自己观点的用户可以通过这种新方式给更受自己喜欢的方案进行投票,同时也可以投票进行重新设计或者取消这项投票。

    3,Edge扩展 Extensions

    微软终于终于终于在Insider预览版Build 14291更新中,带来了这一项很多Insider成员非常期待的特性--Edge浏览器的扩展。





     
    目前只放出了Mouse Gesture、微软Translator和Reddit Engagement Suite这三款扩展程序。考虑到其延展性,相信未来将会支持跟多。

    4,OneDrive 备份选项及占位符

    设置和应用以及个性化设置和密码将支持云端备份,需要指出的是,曾在build 14257中短暂出现的这一特性,已在最新的预览版本中又移除了,相信是还在测试,后续更新肯定会在进一步完善后在Redstone更新中回归。






    OneDrive占位符同步,不用多解释了吧骚年们?在目前的Windows 10版本中微软了取消 Windows 8.1 中引入的OneDrive“占位同步机制”,这个功能允许用户同步云端存储的部分文件,而其余文件默认情况下只会在资源管理器中显示一个缩略图占位符。是一项用户呼声很高的功能,据外媒报道在Windows10重大更新Redstone中该功能将回归。

    5,交互式动态瓷贴 Interactive Live Tiles











    爆炸式瓷贴,更具互动性的瓷贴,讲了好多年了,你懂的!动态磁贴将允许用多种方式与瓷贴进行交互(根据内容与环境),我们继续期待吧……

    6,其他

    其他(是什么鬼)一些微软不愿意泄露的黑科技,仍在路上,也许更多的细节将会在月底召开Build2016大会上公布。
     
    PS:有些童鞋可能会觉得微软一直在画饼,呵呵,各类媒体朋友也各种无知的黑,好似你比谁都懂微软一样在指点江山出谋划策,殊不知那些伟大的科技你可能一辈子也接触不到,既然接触到了也理应心存感激之心吧。放弃那些无意义的谩骂吧,多做些让自己和别人美好的事情。 查看全部


    微软在本月底召开Build2016大会,本次大会上将会重点公开Win10升级系统RedStone的更新内容,微软称这将让世界疯狂。


    Windows团队高级项目经理里奇·特纳最近更是在Twitter上表示:“体验了Windows 10的新功能,等你们看到的时候会疯掉的。”不过他并没有具体透露都有些什么功能。同时,Azure应用平台及工具开发团队的首席项目经理斯科特·汉森尔曼也表示这些新功能“将改变一切”。

    ms_redstone-01.jpg

     
    Windows 10 本身还有相当一部分功能不完善,从更新的Insider预览版进展来看,RedStone应该不会让广大Windows 10用户失望,后续更新也一定会继续加强体验,让我们拭目以待吧。

    在这罗列一些可能将在RedStone更新中发布的功能:

    1,资源管理器 File Explorer

    相比其它方面,微软在Windows 10之中对资源管理器(File Explorer)的更改似乎显得比较保守,仍旧维持固有的操作习惯和界面结构。不过据最新消息,微软团队已经确认正在打造资源管理器的一个全面的更新版本,但并未透露具体计划和细节,消息发布者为Windows核心用户体验部门项目经理Peter Skillman,十分可靠。媒体合理地推测该重新设计的资源管理器或将在Windows 10 Redstone重大更新版本中亮相,或带来标签和触控支持。

    1723066-b363b4ff41d12b53.jpg

     
    2,操作中心 Action Center

    操作中心 Action Center)将有更完善的体验,增强可发现性和呈现更多的信息。微软在尝试更大图标的 Action Center 和跳动的通知图标。

    根据最新的预览版14291中Feedback Hub应用显示,微软以Windows 10通知为例展示两种潜在的通知界面,首先两者的通知区域都远离任务栏,主要差别是右下角图标所显示的位置,第一种方案是在通知图标的基础上从右侧滑入应用图标,第二种则是完全替代通知图标。

    1723066-9e32e3ee4a29e5b2.gif


    1723066-42bf0d562d70fb4b.gif

     
    想要表达自己观点的用户可以通过这种新方式给更受自己喜欢的方案进行投票,同时也可以投票进行重新设计或者取消这项投票。

    3,Edge扩展 Extensions

    微软终于终于终于在Insider预览版Build 14291更新中,带来了这一项很多Insider成员非常期待的特性--Edge浏览器的扩展。

    1723066-608bbb73e1715102.jpg

     
    目前只放出了Mouse Gesture、微软Translator和Reddit Engagement Suite这三款扩展程序。考虑到其延展性,相信未来将会支持跟多。

    4,OneDrive 备份选项及占位符

    设置和应用以及个性化设置和密码将支持云端备份,需要指出的是,曾在build 14257中短暂出现的这一特性,已在最新的预览版本中又移除了,相信是还在测试,后续更新肯定会在进一步完善后在Redstone更新中回归。

    1723066-b95bacf80c41a033.jpg


    OneDrive占位符同步,不用多解释了吧骚年们?在目前的Windows 10版本中微软了取消 Windows 8.1 中引入的OneDrive“占位同步机制”,这个功能允许用户同步云端存储的部分文件,而其余文件默认情况下只会在资源管理器中显示一个缩略图占位符。是一项用户呼声很高的功能,据外媒报道在Windows10重大更新Redstone中该功能将回归。

    5,交互式动态瓷贴 Interactive Live Tiles

    1723066-a2153cb8cf80a9f4.jpg


    1723066-4ad40b9c96cf159c.png


    爆炸式瓷贴,更具互动性的瓷贴,讲了好多年了,你懂的!动态磁贴将允许用多种方式与瓷贴进行交互(根据内容与环境),我们继续期待吧……

    6,其他

    其他(是什么鬼)一些微软不愿意泄露的黑科技,仍在路上,也许更多的细节将会在月底召开Build2016大会上公布。
     
    PS:有些童鞋可能会觉得微软一直在画饼,呵呵,各类媒体朋友也各种无知的黑,好似你比谁都懂微软一样在指点江山出谋划策,殊不知那些伟大的科技你可能一辈子也接触不到,既然接触到了也理应心存感激之心吧。放弃那些无意义的谩骂吧,多做些让自己和别人美好的事情。

    UWP开发入门(四)——自定义CommandBar

    开发中心manupstairs Published the article • 2 comments • 115 views • 2016-01-19 21:27 • 来自相关话题

    各位好,再次回到UWP开发入门系列,刚回归可能有些不适应,所以今天我们讲个简单的,自定义CommandBar,说通俗点就是自定义类似AppBarButton的东西,然后扔到CommandBar中使用。话说为了在公司次世代平台级战略层产品上实现与水果和机器人一致的用户体验,美工把Win10 APP的AppBar也画成左右分开的了,好看是好看了,问题原生的ComandBar控件不支持这么排列啊……头疼归头疼,只能再次展开山寨之路……

    初步思路是在CommandBar中塞进占位用的空白元素,我管它叫AppBarEmpty。那么能放进CommandBar中的元素需要符合什么样的规则呢?首先看一下CommandBar的用法:<CommandBar>
    <AppBarToggleButton Icon="Shuffle" Label="Shuffle" Click="AppBarButton_Click" />
    <AppBarToggleButton Icon="RepeatAll" Label="Repeat" Click="AppBarButton_Click"/>
    <AppBarSeparator/>
    <AppBarButton Icon="Back" Label="Back" Click="AppBarButton_Click"/>
    <AppBarButton Icon="Stop" Label="Stop" Click="AppBarButton_Click"/>
    <AppBarButton Icon="Play" Label="Play" Click="AppBarButton_Click"/>
    <AppBarButton Icon="Forward" Label="Forward" Click="AppBarButton_Click"/>

    <CommandBar.SecondaryCommands>
    <AppBarButton Icon="Like" Label="Like" Click="AppBarButton_Click"/>
    <AppBarButton Icon="Dislike" Label="Dislike" Click="AppBarButton_Click"/>
    </CommandBar.SecondaryCommands>

    <CommandBar.Content>
    <TextBlock Text="Now playing..." Margin="12,14"/>
    </CommandBar.Content>
    </CommandBar>

    上面这个常规的Command显示效果如下图:

    规律还是比较明显的,菜单“like”,“Dislike”均属于SecondaryCommands这个集合,和我们今天的主题关系不大。而最左侧的文字描述是放到CommandBar的Content属性中,也无需理睬。我们需要实现的是将AppButton左右分开,这部分的按钮均属于PrimaryCommands这个集合,XAML没有看到是因为简化写法的缘故。既然属于PrimaryCommands集合的元素会被呈现在按钮区域,那么我们就检查一下该集合的类型定义:
     public IObservableVector<ICommandBarElement> PrimaryCommands { get; }
    很明显该集合的元素需要实现接口ICommandBarElement,而该接口又非常简单://
    // Summary:
    // Defines the compact view for command bar elements.
    [ContractVersion(typeof(UniversalApiContract), 65536)]
    [GuidAttribute(1737592347, 62165, 17617, 139, 132, 146, 184, 127, 128, 163, 80)]
    [WebHostHidden]
    public interface ICommandBarElement
    {
    //
    // Summary:
    // Gets or sets a value that indicates whether the element is shown with no label
    // and reduced padding.
    //
    // Returns:
    // true if the element is shown in its compact state; otherwise, false. The default
    // is false.
    System.Boolean IsCompact { get; set; }
    }
    这样我们的AppBarEmpty就好写了,仅仅需要实现一个IsCompact属性即可,而占位用的AppBarEmpty其实是没有内容的,连IsCompact的效果其实都省了…… public class AppBarEmpty : FrameworkElement, ICommandBarElement
    {
    public bool IsCompact { get; set; }
    }
    是不是有种骗钱的感觉?别走啊,这里还是有讲究的,首先为什么是继承自FrameworkElement呢?

     1.AppEmpty是一个占位控件,基本不具备功能,应该从轻量级的基类继承

     2.FrameworkElement提供了占位所有的Width和Height等属性,更基础的UIElement则没有这些

     3.从FrameworkElement才开始支持的Binding

       搞清楚了以上这些之后,我们兴冲冲的把XAML补完了: <CommandBar>
    <AppBarButton Icon="Accept" Label="Accept"></AppBarButton>
    <AppBarButton Icon="Accept" Label="Accept"></AppBarButton>
    <local:AppBarEmpty></local:AppBarEmpty>
    <AppBarButton Icon="Accept" Label="Accept"></AppBarButton>
    </CommandBar>
    行云流水编译一次通过,嗷嗷的按下F5运行……结果傻眼了……什么效果也没有……介个是为什么呢?

    只能通过Live Tree View来检查了(后面会写一篇介绍Live Tree View,这货简直是神器,现在没有它都不知道怎么调试了……),检查发现AppBarEmpty的Widht是0,而PrimaryCommands集合里的这些按钮又都是放在StackPanel里横向顺序排开的,悲剧的是StackPanle的Width就是几个AppBarButton的Width总和,完全没有留给AppBarEmpty一丝丝的宽度……设置AppBarEmpty的HorizontalAlignment=Stretch对StackPanel是然并卵……

    CommanBar模板PrimaryCommands部分节选: <ItemsControl
    x:Name="PrimaryItemsControl"
    HorizontalAlignment="Right"
    MinHeight="{ThemeResource AppBarThemeMinHeight}"
    IsTabStop="False"
    Grid.Column="1">
    <ItemsControl.ItemsPanel>
    <ItemsPanelTemplate>
    <StackPanel Orientation="Horizontal" />
    </ItemsPanelTemplate>
    </ItemsControl.ItemsPanel>
    </ItemsControl>
      悲剧啊!既然HorizontalAlignment不管用,无法自行撑开。那我们就只有给AppBarEmpty绑定一个确实的Width了。对应的XAML如下:<Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    <Grid.RowDefinitions>
    <RowDefinition></RowDefinition>
    <RowDefinition Height="Auto"></RowDefinition>
    <RowDefinition Height="Auto"></RowDefinition>
    <RowDefinition x:Name="RowBottom" Height="Auto"></RowDefinition>
    </Grid.RowDefinitions>

    <TextBox Grid.Row="1"> </TextBox>

    <CommandBar x:Name="commandBar" Grid.Row="2">
    <AppBarButton x:Name="appbarButton" Icon="Accept" Label="Accept"></AppBarButton>
    <AppBarButton Icon="Accept" Label="Accept"></AppBarButton>
    <local:AppBarEmpty Width="{x:Bind TestWidth,Mode=OneWay}"></local:AppBarEmpty>
    <AppBarButton Icon="Accept" Label="Accept"></AppBarButton>
    </CommandBar>

    </Grid>
    为AppBarEmpty做了XBind到TestWidth属性上,相应的Page的代码里定义了该属性,并在Page的SizeChanged事件中计算了AppBarEmpty实际需要的宽度。public sealed partial class MainPage : Page, INotifyPropertyChanged
    {
    public double TestWidth { get; set; }

    public MainPage()
    {
    this.InitializeComponent();
    this.SizeChanged += MainPage_SizeChanged;
    }

    public event PropertyChangedEventHandler PropertyChanged;

    private void MainPage_SizeChanged(object sender, SizeChangedEventArgs e)
    {
    int count = this.commandBar.PrimaryCommands.Count-1;
    double width = (this.commandBar.PrimaryCommands[0] as AppBarButton).ActualWidth;
    TestWidth = e.NewSize.Width - count* width -48;
    this.OnPropertyChanged("TestWidth");
    }

    public void OnPropertyChanged([CallerMemberName]string name = null)
    {
    this.PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
    }
    }
    代码中减掉的48是CommandBar最右边“…”按钮的宽度。实际显示如下图:

    这里仍然存在几个问题:

     

    1.有童鞋说为什么不自己写个RelativePanel,然后里面的按钮就可以随便对齐定位了。

    该方法确实可行,但等于抛弃了CommandBar,也无法集成到Page的TopAppBar、BottomAppBar中使用。有点偏离了我们自定义CommadBar的初衷。并且要想完整实现一套CommandBar的工作量还是不小的

    2.实现的方式不够优美,竟然使用了SizeChanged事件来计算Width。简直返古到了WinForm的时代。

    哼哼,兄弟我不想好解决方案敢写这篇被你们骂?当然是已经准备好了完美的解决方案才来写这篇钓鱼咯,乖乖给我点个推荐,然后我们下周见…… 查看全部
    各位好,再次回到UWP开发入门系列,刚回归可能有些不适应,所以今天我们讲个简单的,自定义CommandBar,说通俗点就是自定义类似AppBarButton的东西,然后扔到CommandBar中使用。话说为了在公司次世代平台级战略层产品上实现与水果和机器人一致的用户体验,美工把Win10 APP的AppBar也画成左右分开的了,好看是好看了,问题原生的ComandBar控件不支持这么排列啊……头疼归头疼,只能再次展开山寨之路……

    初步思路是在CommandBar中塞进占位用的空白元素,我管它叫AppBarEmpty。那么能放进CommandBar中的元素需要符合什么样的规则呢?首先看一下CommandBar的用法:
    <CommandBar>
    <AppBarToggleButton Icon="Shuffle" Label="Shuffle" Click="AppBarButton_Click" />
    <AppBarToggleButton Icon="RepeatAll" Label="Repeat" Click="AppBarButton_Click"/>
    <AppBarSeparator/>
    <AppBarButton Icon="Back" Label="Back" Click="AppBarButton_Click"/>
    <AppBarButton Icon="Stop" Label="Stop" Click="AppBarButton_Click"/>
    <AppBarButton Icon="Play" Label="Play" Click="AppBarButton_Click"/>
    <AppBarButton Icon="Forward" Label="Forward" Click="AppBarButton_Click"/>

    <CommandBar.SecondaryCommands>
    <AppBarButton Icon="Like" Label="Like" Click="AppBarButton_Click"/>
    <AppBarButton Icon="Dislike" Label="Dislike" Click="AppBarButton_Click"/>
    </CommandBar.SecondaryCommands>

    <CommandBar.Content>
    <TextBlock Text="Now playing..." Margin="12,14"/>
    </CommandBar.Content>
    </CommandBar>


    上面这个常规的Command显示效果如下图:

    规律还是比较明显的,菜单“like”,“Dislike”均属于SecondaryCommands这个集合,和我们今天的主题关系不大。而最左侧的文字描述是放到CommandBar的Content属性中,也无需理睬。我们需要实现的是将AppButton左右分开,这部分的按钮均属于PrimaryCommands这个集合,XAML没有看到是因为简化写法的缘故。既然属于PrimaryCommands集合的元素会被呈现在按钮区域,那么我们就检查一下该集合的类型定义:
     
    public IObservableVector<ICommandBarElement> PrimaryCommands { get; }

    很明显该集合的元素需要实现接口ICommandBarElement,而该接口又非常简单:
    //
    // Summary:
    // Defines the compact view for command bar elements.
    [ContractVersion(typeof(UniversalApiContract), 65536)]
    [GuidAttribute(1737592347, 62165, 17617, 139, 132, 146, 184, 127, 128, 163, 80)]
    [WebHostHidden]
    public interface ICommandBarElement
    {
    //
    // Summary:
    // Gets or sets a value that indicates whether the element is shown with no label
    // and reduced padding.
    //
    // Returns:
    // true if the element is shown in its compact state; otherwise, false. The default
    // is false.
    System.Boolean IsCompact { get; set; }
    }

    这样我们的AppBarEmpty就好写了,仅仅需要实现一个IsCompact属性即可,而占位用的AppBarEmpty其实是没有内容的,连IsCompact的效果其实都省了……
        public class AppBarEmpty : FrameworkElement, ICommandBarElement
    {
    public bool IsCompact { get; set; }
    }

    是不是有种骗钱的感觉?别走啊,这里还是有讲究的,首先为什么是继承自FrameworkElement呢?

     1.AppEmpty是一个占位控件,基本不具备功能,应该从轻量级的基类继承

     2.FrameworkElement提供了占位所有的Width和Height等属性,更基础的UIElement则没有这些

     3.从FrameworkElement才开始支持的Binding

       搞清楚了以上这些之后,我们兴冲冲的把XAML补完了:
            <CommandBar>
    <AppBarButton Icon="Accept" Label="Accept"></AppBarButton>
    <AppBarButton Icon="Accept" Label="Accept"></AppBarButton>
    <local:AppBarEmpty></local:AppBarEmpty>
    <AppBarButton Icon="Accept" Label="Accept"></AppBarButton>
    </CommandBar>

    行云流水编译一次通过,嗷嗷的按下F5运行……结果傻眼了……什么效果也没有……介个是为什么呢?

    只能通过Live Tree View来检查了(后面会写一篇介绍Live Tree View,这货简直是神器,现在没有它都不知道怎么调试了……),检查发现AppBarEmpty的Widht是0,而PrimaryCommands集合里的这些按钮又都是放在StackPanel里横向顺序排开的,悲剧的是StackPanle的Width就是几个AppBarButton的Width总和,完全没有留给AppBarEmpty一丝丝的宽度……设置AppBarEmpty的HorizontalAlignment=Stretch对StackPanel是然并卵……

    CommanBar模板PrimaryCommands部分节选:
                <ItemsControl
    x:Name="PrimaryItemsControl"
    HorizontalAlignment="Right"
    MinHeight="{ThemeResource AppBarThemeMinHeight}"
    IsTabStop="False"
    Grid.Column="1">
    <ItemsControl.ItemsPanel>
    <ItemsPanelTemplate>
    <StackPanel Orientation="Horizontal" />
    </ItemsPanelTemplate>
    </ItemsControl.ItemsPanel>
    </ItemsControl>

      悲剧啊!既然HorizontalAlignment不管用,无法自行撑开。那我们就只有给AppBarEmpty绑定一个确实的Width了。对应的XAML如下:
    <Grid Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">
    <Grid.RowDefinitions>
    <RowDefinition></RowDefinition>
    <RowDefinition Height="Auto"></RowDefinition>
    <RowDefinition Height="Auto"></RowDefinition>
    <RowDefinition x:Name="RowBottom" Height="Auto"></RowDefinition>
    </Grid.RowDefinitions>

    <TextBox Grid.Row="1"> </TextBox>

    <CommandBar x:Name="commandBar" Grid.Row="2">
    <AppBarButton x:Name="appbarButton" Icon="Accept" Label="Accept"></AppBarButton>
    <AppBarButton Icon="Accept" Label="Accept"></AppBarButton>
    <local:AppBarEmpty Width="{x:Bind TestWidth,Mode=OneWay}"></local:AppBarEmpty>
    <AppBarButton Icon="Accept" Label="Accept"></AppBarButton>
    </CommandBar>

    </Grid>

    为AppBarEmpty做了XBind到TestWidth属性上,相应的Page的代码里定义了该属性,并在Page的SizeChanged事件中计算了AppBarEmpty实际需要的宽度。
    public sealed partial class MainPage : Page, INotifyPropertyChanged
    {
    public double TestWidth { get; set; }

    public MainPage()
    {
    this.InitializeComponent();
    this.SizeChanged += MainPage_SizeChanged;
    }

    public event PropertyChangedEventHandler PropertyChanged;

    private void MainPage_SizeChanged(object sender, SizeChangedEventArgs e)
    {
    int count = this.commandBar.PrimaryCommands.Count-1;
    double width = (this.commandBar.PrimaryCommands[0] as AppBarButton).ActualWidth;
    TestWidth = e.NewSize.Width - count* width -48;
    this.OnPropertyChanged("TestWidth");
    }

    public void OnPropertyChanged([CallerMemberName]string name = null)
    {
    this.PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(name));
    }
    }

    代码中减掉的48是CommandBar最右边“…”按钮的宽度。实际显示如下图:

    这里仍然存在几个问题:

     

    1.有童鞋说为什么不自己写个RelativePanel,然后里面的按钮就可以随便对齐定位了。

    该方法确实可行,但等于抛弃了CommandBar,也无法集成到Page的TopAppBar、BottomAppBar中使用。有点偏离了我们自定义CommadBar的初衷。并且要想完整实现一套CommandBar的工作量还是不小的

    2.实现的方式不够优美,竟然使用了SizeChanged事件来计算Width。简直返古到了WinForm的时代。

    哼哼,兄弟我不想好解决方案敢写这篇被你们骂?当然是已经准备好了完美的解决方案才来写这篇钓鱼咯,乖乖给我点个推荐,然后我们下周见……

    【通知】如何正确、有效的使用WinEcos社区?

    会员讨论Nokiss Published the article • 10 comments • 386 views • 2016-01-08 11:53 • 来自相关话题

    WinEcos是全称为Win Ecosystem的简写,中文翻译为:"赢在生态" 。WinEcos社区因"兴趣、激情、热爱"而发起,所以我们非常愿意与您分享关于各个的各种资讯。

     
    社区致力于为Windows、物联网(IoT)等业内的消费者、开发者、厂商以及生态产业链上的用户提供专业、高效的解决方案及由价值的业界资讯,;其中,我们侧重为开发者提供一个良好的交流氛围。

    普通消费者亦可在社区内提出您所关心的问题,涵盖Windows,物联网(IoT)的方方面面。 WinEcos社区运营团队不大,难免会出现各种错误,我们会尽最大努力保证社区正常运转。WinEcos社区不代表任何厂商的官方言论,我们属于第三方社区,所有的信息均出自WinEcos会员。
     
    WinEcos是个开放性社区,你有任何疑问或者建议皆可在社区反馈,WinEcos是有区别于贴吧和论坛的,而目前的社区氛围也是大家共同努力下营造的,再此我代表WinEcos管理层对各位WinEcos的会员以最诚挚的感谢。
     
    如何更好使用WinEcos社区呢,如何提问?发布文章?
     
    1,普通用户在注册成功后皆可在WinEcos提问
     
    a) 用户提问前,先搜索(页面顶部搜索框)是否有相关类似的问题,以便更快得到解决方案,避免重复帖;
    b) 提问要求,标题清晰、简短、明确;
    c) 正文内容要求问题描述清楚,通俗易懂,图文并茂为最佳,且行文格式规范;
    d) 添加话题,至少添加1到2个话题标签,以问题内容侧重点而定,以方便其他用户搜索;
    e) 普通用户可以在您发言后 30 分钟内编辑回复过的内容;
    f) 对于您认为精彩、准确的回复,可以进行点赞、收藏或分享,严禁灌水;
    (别吝惜点赞,这是正确、精彩回复得到曝光的最有效方式,WinEcos对于赞数多者是自动排第一位的)
     
    2,文章,目前未向普通用户开启
     
    文章,顾名思义,要求更高、更严谨。 
    涵盖:发表个人看法和观点,分享心得体会;个人评测;新闻资讯;通知通告等等
    要求:同上面提问要求,但更具严谨性。
    开通方式:私信站长或投稿皆可
     
    @wakaka :遵循社区规则,才能使社区有序生存,才不至于于贴吧同质,希望大家都改掉那些那些在贴吧发帖的习惯。
    认真思考一下,自己要发表的东西是问题还是文章,很有必要!

    3,WinEcos积分说明 
     
    亦可在发起问题/文章,底部确认发起按钮旁边[积分规则]查看! 查看全部
    winecos-logo.png


    WinEcos是全称为Win Ecosystem的简写,中文翻译为:"赢在生态" 。WinEcos社区因"兴趣、激情、热爱"而发起,所以我们非常愿意与您分享关于各个的各种资讯。


     
    社区致力于为Windows、物联网(IoT)等业内的消费者、开发者、厂商以及生态产业链上的用户提供专业、高效的解决方案及由价值的业界资讯,;其中,我们侧重为开发者提供一个良好的交流氛围。

    普通消费者亦可在社区内提出您所关心的问题,涵盖Windows,物联网(IoT)的方方面面。 WinEcos社区运营团队不大,难免会出现各种错误,我们会尽最大努力保证社区正常运转。WinEcos社区不代表任何厂商的官方言论,我们属于第三方社区,所有的信息均出自WinEcos会员。
     
    WinEcos是个开放性社区,你有任何疑问或者建议皆可在社区反馈,WinEcos是有区别于贴吧和论坛的,而目前的社区氛围也是大家共同努力下营造的,再此我代表WinEcos管理层对各位WinEcos的会员以最诚挚的感谢。
     
    如何更好使用WinEcos社区呢,如何提问?发布文章?
     
    1,普通用户在注册成功后皆可在WinEcos提问
     
    a) 用户提问前,先搜索(页面顶部搜索框)是否有相关类似的问题,以便更快得到解决方案,避免重复帖
    b) 提问要求,标题清晰、简短、明确
    c) 正文内容要求问题描述清楚通俗易懂,图文并茂为最佳,且行文格式规范
    d) 添加话题,至少添加1到2个话题标签,以问题内容侧重点而定,以方便其他用户搜索;
    e) 普通用户可以在您发言后 30 分钟内编辑回复过的内容;
    f) 对于您认为精彩、准确的回复,可以进行点赞收藏分享,严禁灌水;
    (别吝惜点赞,这是正确、精彩回复得到曝光的最有效方式,WinEcos对于赞数多者是自动排第一位的)
     
    2,文章,目前未向普通用户开启
     
    文章,顾名思义,要求更高、更严谨。 
    涵盖:发表个人看法和观点,分享心得体会;个人评测;新闻资讯;通知通告等等
    要求:同上面提问要求,但更具严谨性。
    开通方式:私信站长或投稿皆可
     
    @wakaka :遵循社区规则,才能使社区有序生存,才不至于于贴吧同质,希望大家都改掉那些那些在贴吧发帖的习惯。
    认真思考一下,自己要发表的东西是问题还是文章,很有必要!


    3,WinEcos积分说明 
     
    亦可在发起问题/文章,底部确认发起按钮旁边[积分规则]查看!

    2016-01-08_104400.png

    如何将UWP版微博安装在手机上?兼有道词典UWP版

    会员讨论wakaka Published the article • 3 comments • 219 views • 2016-01-05 08:23 • 来自相关话题

     
    手机部署了 电脑UWP版的新浪微博,目前还没有优化。
    需要手机升级到win 10,然后设置里开启开发者模式,才能安装。
    可流畅使用

    Appx安装包地址:
    http://pan.baidu.com/s/1nucHFw1
     
     
    有道词典的MS商店文件地址:
    http://dl.delivery.mp.microsoft.com/filestreamingservice/files/6e140cef-1e11-4e8b-a377-e3696d41874f
    可成功安装,正常使用
     
     
    优酷视频UWP版MS商店文件地址:
    http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/c9550634-bc79-47d0-a88c-27174082e2b8?P1=1451955940&P2=301&P3=2&P4=SDEnH8J9W58E%2b4gu%2fV0EU5yWcxqJmv4q9zUd7AJcQ8U%3d
    界面未适配


    爱奇艺UWP版文件地址:
    http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/def47718-3b18-47fb-bb8f-6ba6ea47ee08?P1=1451955924&P2=301&P3=2&P4=pZgMepWoX4DZCS%2fVlCgN8Y1pNdQ64Xn60ANJLscskPc%3d
    应用打开后无法获得数据


    网易云音乐UWP,Camera 360 UWP不支持ARM,所以无法安装。
      查看全部


     
    手机部署了 电脑UWP版的新浪微博,目前还没有优化。
    需要手机升级到win 10,然后设置里开启开发者模式,才能安装。

    可流畅使用


    Appx安装包地址:
    http://pan.baidu.com/s/1nucHFw1
     
     
    有道词典的MS商店文件地址:
    http://dl.delivery.mp.microsoft.com/filestreamingservice/files/6e140cef-1e11-4e8b-a377-e3696d41874f
    可成功安装,正常使用
     
     
    优酷视频UWP版MS商店文件地址:
    http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/c9550634-bc79-47d0-a88c-27174082e2b8?P1=1451955940&P2=301&P3=2&P4=SDEnH8J9W58E%2b4gu%2fV0EU5yWcxqJmv4q9zUd7AJcQ8U%3d
    界面未适配


    爱奇艺UWP版文件地址:
    http://tlu.dl.delivery.mp.microsoft.com/filestreamingservice/files/def47718-3b18-47fb-bb8f-6ba6ea47ee08?P1=1451955924&P2=301&P3=2&P4=pZgMepWoX4DZCS%2fVlCgN8Y1pNdQ64Xn60ANJLscskPc%3d
    应用打开后无法获得数据


    网易云音乐UWP,Camera 360 UWP不支持ARM,所以无法安装。
     

    欢迎软粉们一起来用“消息+Skype”应用在线聊天

    会员讨论jasonyeung Replyed • 10 person concerned • 10 replies • 248 views • 2015-12-28 11:09 • 来自相关话题

    【线下活动】Lumia 950&950XL上市粉丝体验会

    会员讨论微士博 Published the article • 13 comments • 383 views • 2015-12-15 11:49 • 来自相关话题

    Lumia 950&950XL上市粉丝体验会,全国10大城市体验,详情看下面:





     
    活动时间、地点及城市: 





     
     
    报名地址:http://winecos.mikecrm.com/f.php?t=H6qXs5 
      查看全部
    Lumia 950&950XL上市粉丝体验会,全国10大城市体验,详情看下面:

    screen1_pic_01.png

     
    活动时间、地点及城市: 

    001.png

     
     
    报名地址:http://winecos.mikecrm.com/f.php?t=H6qXs5 
     

    【首发团购套餐】微软移动新品Lumia950/XL购买福利细则正式公布!

    会员讨论微士博 Published the article • 95 comments • 1868 views • 2015-12-01 09:58 • 来自相关话题

    版权声明
    本文发自WinEcos社区: http://winecos.com ;
    作者: WinEcos
    需授权转载,自觉保留以上版权声明。
     
    首先,感谢社区会员对本次活动的鼎力支持,不管您最终是否购买团购的产品,终究是对WinEcos的一种支持,感谢!下面的信息,请大家一定要仔细看,注意细节,任何疑问,请单独开贴询问,格式如下:
    标题:【团购疑问】xxxxxxxxxxxxxxx
    能够公布给会员的,我将尽力为大家作解答!
     
    WinEcos首次团购产品:
    (1) 微软Lumia950 手机裸机; 全国统一售价:3999元;
    (2) 微软Lumia950XL + 微软通用折叠键盘套装;全国统一售价:5499元;
    备注:
      (a)Lumia950XL在全国市场均无裸机销售,只有套装销售;
      (b)手机和键盘放置于同一个包装盒内;
     
    团购活动内容:
    成团条件:团购微软手机新品 Lumia 950或950XL,两个型号原价购买数量累计满240台即成团。
    团购内容:活动期间,原价购买Lumia 950或950XL键盘套装,即特别赠送“微软显示扩展坞,市场价值699元”;我们承诺参团的每一个会员在付款下单成功后,都可以拿到微软显示扩展坞。
    购买渠道:天猫微软官方旗舰店
     
    独家福利一:
    您收到机器后,去微软天猫官方旗舰店做产品好评,即再额外赠送4款产品(正在协商直接一次性发送):
     (1) Lumia 950/950XL专用钢化膜;
     (2) BH-112蓝牙耳机;
     (3) 微软10000mAh以上移动电源;
     (4) 32G/64G SD内存卡
    *收货后的好评截图给到旺旺客服,与客服确认,赠品会单独寄出。
    *Lumia 950 赠品为闪迪32G TF卡;Lumia 950XL 赠品为金士顿64GB TF内存卡。
     
    独家福利二:
    所有参团粉丝会员,均可获得额外一年机器质量延展保修服务(国家三包标准是1年质保;即总共2年质保)
    会在发票上标注这一信息,例如:Lumia950-两年质保或者在备注栏标注。
     
    具体操作流程如下:
    1. 团购会员, 通过平台指定的专有活动代码领取礼品 ( 后台邮件通知) .
    2. 粉丝在“微软中国官方旗舰店”(https://microsoftstore.tmall.com)购买Lumia950/950XL,并成功付款后,向旺旺客服出示所得的专有代码,即可免费获赠微软显示扩展坞.
    3. 微软旗舰店客服检测代码的有效性,为顾客额外配置相应赠品,并标记相关代码的使用;
    4. 粉丝收到Lumia950/950XL以及微软显示扩展坞后,登陆微软旗舰店给产品好评截图反馈, 客服会安排赠品单独补发;
     
    付款时间:2015年12月8日~~2015年12月9日,总计两天.
    发货时间:2015年12月18日,全国统一发货,当然,我们拿到的时间会比这个要提前滴.
    产品快递:顺丰速运

    退换货条款:
     商品自签收起14日内可退货,15天内可换货,因电子产品的特殊性,享受14天无理由退款的必要条件为商品未使用过、未拆封、未破坏原包装且配件及赠品完好齐全,不影响二次销售;如商品无质量问题且已经拆封 或者影响二次销售则不可退货。
     
    WinEcos能够做什么?
    1,解答任何购买过程中的疑问。
    2,解答任何关于设备,系统,软件方面的售后咨询服务。
    3,提供您晒美图,评测的平台。
    4,我们强烈建议您在拿到产品后,到社区发帖晒图!^_^
     
    再次声明:
    WinEcos选择与微软官方的TMALL旗舰店合作,首次团购不经手任何产品、款项,请放心购买!
     
    两张图说明本次团购的价格及产品:
    Lumia 950XL套餐如下:




     
    Lumia 950套餐如下: 查看全部
    版权声明
    本文发自WinEcos社区: http://winecos.com ;
    作者: WinEcos
    需授权转载,自觉保留以上版权声明。

     
    首先,感谢社区会员对本次活动的鼎力支持,不管您最终是否购买团购的产品,终究是对WinEcos的一种支持,感谢!下面的信息,请大家一定要仔细看,注意细节,任何疑问,请单独开贴询问,格式如下:
    标题:【团购疑问】xxxxxxxxxxxxxxx
    能够公布给会员的,我将尽力为大家作解答!
     
    WinEcos首次团购产品:
    (1) 微软Lumia950 手机裸机; 全国统一售价:3999元;
    (2) 微软Lumia950XL + 微软通用折叠键盘套装;全国统一售价:5499元;
    备注:
      (a)Lumia950XL在全国市场均无裸机销售,只有套装销售;
      (b)手机和键盘放置于同一个包装盒内;
     
    团购活动内容:
    成团条件:团购微软手机新品 Lumia 950或950XL,两个型号原价购买数量累计满240台即成团。
    团购内容:活动期间,原价购买Lumia 950或950XL键盘套装,即特别赠送“微软显示扩展坞,市场价值699元”;我们承诺参团的每一个会员在付款下单成功后,都可以拿到微软显示扩展坞。
    购买渠道:天猫微软官方旗舰店
     
    独家福利一:
    您收到机器后,去微软天猫官方旗舰店做产品好评,即再额外赠送4款产品(正在协商直接一次性发送):
     (1) Lumia 950/950XL专用钢化膜;
     (2) BH-112蓝牙耳机;
     (3) 微软10000mAh以上移动电源;
     (4) 32G/64G SD内存卡
    *收货后的好评截图给到旺旺客服,与客服确认,赠品会单独寄出。
    *Lumia 950 赠品为闪迪32G TF卡;Lumia 950XL 赠品为金士顿64GB TF内存卡。
     
    独家福利二:
    所有参团粉丝会员,均可获得额外一年机器质量延展保修服务(国家三包标准是1年质保;即总共2年质保)
    会在发票上标注这一信息,例如:Lumia950-两年质保或者在备注栏标注。
     
    具体操作流程如下:
    1. 团购会员, 通过平台指定的专有活动代码领取礼品 ( 后台邮件通知) .
    2. 粉丝在“微软中国官方旗舰店”(https://microsoftstore.tmall.com)购买Lumia950/950XL,并成功付款后,向旺旺客服出示所得的专有代码,即可免费获赠微软显示扩展坞.
    3. 微软旗舰店客服检测代码的有效性,为顾客额外配置相应赠品,并标记相关代码的使用;
    4. 粉丝收到Lumia950/950XL以及微软显示扩展坞后,登陆微软旗舰店给产品好评截图反馈, 客服会安排赠品单独补发;
     
    付款时间:2015年12月8日~~2015年12月9日,总计两天.
    发货时间:2015年12月18日,全国统一发货,当然,我们拿到的时间会比这个要提前滴.
    产品快递:顺丰速运

    退换货条款:
     商品自签收起14日内可退货,15天内可换货,因电子产品的特殊性,享受14天无理由退款的必要条件为商品未使用过、未拆封、未破坏原包装且配件及赠品完好齐全,不影响二次销售;如商品无质量问题且已经拆封 或者影响二次销售则不可退货。
     
    WinEcos能够做什么?
    1,解答任何购买过程中的疑问。
    2,解答任何关于设备,系统,软件方面的售后咨询服务。
    3,提供您晒美图,评测的平台。
    4,我们强烈建议您在拿到产品后,到社区发帖晒图!^_^
     
    再次声明:
    WinEcos选择与微软官方的TMALL旗舰店合作,首次团购不经手任何产品、款项,请放心购买!
     
    两张图说明本次团购的价格及产品:
    Lumia 950XL套餐如下:
    950XL.png

     
    Lumia 950套餐如下:
    Lumia950.png

    【WE云10代系列课程之】DocumentDB概述

    Azure微士博 Published the article • 0 comments • 171 views • 2015-11-30 15:56 • 来自相关话题

    版权声明
    本文发自WinEcos社区: http://winecos.com ;
    作者:微士博
    无需授权即可转载,但请自觉保留以上版权声明。

    这一个月,我们都沉浸在微软移动新品Lumia 950/XL的预售中,各位会员也期望能尽早拿到设备,Me too ! ,但正所谓"好饭不怕晚", coser们耐心等待几日, 我相信这种等待是值得的。12月1日(明天),我们会公布所有的操作细节,包括:售价、套餐内容、发货方式、保修政策、付款时间、售后服务等等.
     
    为什么要做“WE云10代"系列课程?
    “WE云10代" 即:WE=WinEcos, 取两个字母, 云=围绕Azure云, AWS云的相关技术与运维 , 10代=Windows 10。这样的解释,您明白了么?
     概括起来的意思就是:“以Windows 作为服务,在"云中"了解那些有趣的技术, 构建云生态圈, 在这之中,愿WinEcos社区,能够给您提供一个融合的沟通交流平台" .
     
    为什么选择以"DocumentDB"为切入点 ? 
    我们常用的查询工具 http://tools.winecos.com  就是用DocumentDB+Node.js处理的,所以,这是最好的教材。
     
    在这篇文章中,您将了解到:
    什么是Azure DocumentDB ?
    DocumentDB资源结构是什么?
    如何使用DocumentDB进行开发?
     
    DocumentDB是一个类似MongoDB的NoSQL文档数据库,对,它就是微软在家推荐的NoSQL数据库解决方案,针对大数据解决方案而提供的服务,基于JSON数据格式,在可伸缩性及高可用性方面表现突出, 当下,各种服务,应用程序对数据的需求越来越多,越快,这就要求基础的服务架构也要适时应对这些变化,但传统的RMDB的结构有一定的局限性,所以,现在很多开发者或ISV,都选择NoSQL文档数据库作为简单,快速,可扩展的解决方案来存储和处理数据,NoSQL文档数据库同时保留了快速便利应用程序模型的能力和非结构化数据源的能力,这些信息,如果您对MongoDB有所了解,应可以理解. DocumentDB允许使用SQL语言进行查询,并可以使用存储过程,触发器和UDF的JS语言集成,多文档的事物处理.
     
    DocumentDB有如下关键的功能与优点:
    熟悉的SQL语法查询:  JSON文档作为DocumentDB的主要存储文件,查询这些文档内容则使用我们非常熟悉的SQL语法,日志文件也支持快速的的索引等.
    在数据库中执行Javascript: 这主要针对的是在服务器端的编程模型, 像存储过程,触发器,UDF(User Defined Functions)都可以以Javascript形式执行, 整个过程类似如下图所示:





          
          可调节的一致性水平:这个功能主要针对开发人员或运维来讲述,我在实际的操作中用到的较少,不做过多描述,如果有了解这些特性的朋友,可以单独写一篇文章来描述下。
            放手原则:有过数据库开发经验的朋友一定会对维护数据库表或者服务器资源问题而苦恼过,比如:管理虚拟机,部署和配置环境等,使用DocumentDB,你就不需要处理这些事情,让你更加专注在应用程序的开发上面。
    弹性可扩展的IO与存储:根据你的业务需求,非常方便的扩大或缩小你的DocumentDB数据库,缩放则是通过预留出SSD支持的存储和IO粒度进行,主要是指集合。回头等我尝试下再分享.
    开放式的设计:在我的理解中,这主要指的是你可以非常迅速及方便的使用现有工具来对DocumentDB进行开发设计,不需要再学习什么新的技能, 容我再深入理解理解 ^_^.
     
    DocumentDB资源结构
    Azure DocumentDB管理数据是通过定义良好的数据库资源, 这些资源可以实现高可用性,DocumentDB是基于简单的HTTP REST风格的编程模型来操作,可参考下面的结构图,对DocumentDB有个大概的了解:





    注意:您可以创建多个数据库账号,每个账号可以包含多个集合,每个即合理可以创建多个存储过程,触发器,UDF等. 您也可以对单个数据库设置访问权限。
     
    如何使用熟悉的语言对DocumentDB进行开发?
    前面提到过,DocumentDB采用HTTP的REST API形式访问资源,这就是说它支持多数流行的编程语言,可参考下表:
    .NET
    Node.js
    Java
    Javascript
    Server-side Javascript SDK
    Python
     
    你可以使用自己熟悉的编程语言开发DocumentDB应用,网站等,
     
    至此,相信你大概了解了DocumentDB到底是什么,支持哪些语言的开发,结构如何,有哪些优势,下一篇文章,我将给大家介绍下如何导入数据到DocumentDB中.
     
    其实,概述性的文章讲的都非常宽泛,技术需要用到才能深入的去学习,去理解个中的知识点,但总归要有一个开始嘛… *_*
     
    2015年11月30日,北京办公室记录. 查看全部
    版权声明
    本文发自WinEcos社区: http://winecos.com ;
    作者:微士博
    无需授权即可转载,但请自觉保留以上版权声明。


    这一个月,我们都沉浸在微软移动新品Lumia 950/XL的预售中,各位会员也期望能尽早拿到设备,Me too ! ,但正所谓"好饭不怕晚", coser们耐心等待几日, 我相信这种等待是值得的。12月1日(明天),我们会公布所有的操作细节,包括:售价、套餐内容、发货方式、保修政策、付款时间、售后服务等等.
     
    为什么要做“WE云10代"系列课程?
    “WE云10代" 即:WE=WinEcos, 取两个字母, 云=围绕Azure云, AWS云的相关技术与运维 , 10代=Windows 10。这样的解释,您明白了么?
     概括起来的意思就是:“以Windows 作为服务,在"云中"了解那些有趣的技术, 构建云生态圈, 在这之中,愿WinEcos社区,能够给您提供一个融合的沟通交流平台" .
     
    为什么选择以"DocumentDB"为切入点 ? 
    我们常用的查询工具 http://tools.winecos.com  就是用DocumentDB+Node.js处理的,所以,这是最好的教材。
     
    在这篇文章中,您将了解到:
    什么是Azure DocumentDB ?
    DocumentDB资源结构是什么?
    如何使用DocumentDB进行开发?
     
    DocumentDB是一个类似MongoDB的NoSQL文档数据库,对,它就是微软在家推荐的NoSQL数据库解决方案,针对大数据解决方案而提供的服务,基于JSON数据格式,在可伸缩性及高可用性方面表现突出, 当下,各种服务,应用程序对数据的需求越来越多,越快,这就要求基础的服务架构也要适时应对这些变化,但传统的RMDB的结构有一定的局限性,所以,现在很多开发者或ISV,都选择NoSQL文档数据库作为简单,快速,可扩展的解决方案来存储和处理数据,NoSQL文档数据库同时保留了快速便利应用程序模型的能力和非结构化数据源的能力,这些信息,如果您对MongoDB有所了解,应可以理解. DocumentDB允许使用SQL语言进行查询,并可以使用存储过程,触发器和UDF的JS语言集成,多文档的事物处理.
     
    DocumentDB有如下关键的功能与优点:
    熟悉的SQL语法查询:  JSON文档作为DocumentDB的主要存储文件,查询这些文档内容则使用我们非常熟悉的SQL语法,日志文件也支持快速的的索引等.
    在数据库中执行Javascript: 这主要针对的是在服务器端的编程模型, 像存储过程,触发器,UDF(User Defined Functions)都可以以Javascript形式执行, 整个过程类似如下图所示:

    001.png

          
          可调节的一致性水平:这个功能主要针对开发人员或运维来讲述,我在实际的操作中用到的较少,不做过多描述,如果有了解这些特性的朋友,可以单独写一篇文章来描述下。
            放手原则:有过数据库开发经验的朋友一定会对维护数据库表或者服务器资源问题而苦恼过,比如:管理虚拟机,部署和配置环境等,使用DocumentDB,你就不需要处理这些事情,让你更加专注在应用程序的开发上面。
    弹性可扩展的IO与存储:根据你的业务需求,非常方便的扩大或缩小你的DocumentDB数据库,缩放则是通过预留出SSD支持的存储和IO粒度进行,主要是指集合。回头等我尝试下再分享.
    开放式的设计:在我的理解中,这主要指的是你可以非常迅速及方便的使用现有工具来对DocumentDB进行开发设计,不需要再学习什么新的技能, 容我再深入理解理解 ^_^.
     
    DocumentDB资源结构
    Azure DocumentDB管理数据是通过定义良好的数据库资源, 这些资源可以实现高可用性,DocumentDB是基于简单的HTTP REST风格的编程模型来操作,可参考下面的结构图,对DocumentDB有个大概的了解:

    002.png

    注意:您可以创建多个数据库账号,每个账号可以包含多个集合,每个即合理可以创建多个存储过程,触发器,UDF等. 您也可以对单个数据库设置访问权限。
     
    如何使用熟悉的语言对DocumentDB进行开发?
    前面提到过,DocumentDB采用HTTP的REST API形式访问资源,这就是说它支持多数流行的编程语言,可参考下表:
    .NET
    Node.js
    Java
    Javascript
    Server-side Javascript SDK
    Python
     
    你可以使用自己熟悉的编程语言开发DocumentDB应用,网站等,
     
    至此,相信你大概了解了DocumentDB到底是什么,支持哪些语言的开发,结构如何,有哪些优势,下一篇文章,我将给大家介绍下如何导入数据到DocumentDB中.
     
    其实,概述性的文章讲的都非常宽泛,技术需要用到才能深入的去学习,去理解个中的知识点,但总归要有一个开始嘛… *_*
     
    2015年11月30日,北京办公室记录.