设计通知，工程联系单，工作联系单，设计变更，变更设计各是什么意思

就我做过的回答

设计通知：这个没接触过应该是，工程中设计院单方做的改动，做出蓝图修改通知

工程联系单：与甲方沟通的，正式书面文书，以备后查，涉及重要事宜需双方盖章

工作联系单：与上面差别不大，区别在于这个类似日记，上面是月汇总

设计变更：施工中，乙方发现不符合现场施工情况，或者甲方为方便使用修改

然后通知设计院出具的图纸更改

变更设计：与上面基本用途一样。

以上五个名称，其实就两个主题，一个是乙方与甲方联系，一个是乙方与设计院联系

，可能一些超正规的工程会分开使用，具体没接触过

城市规划行政主管部门在接到建设单位申请规划设计条件后,应该根据城市规划,有关法律、法规和技术规范、技术标准,无论是对修建性详细规划的还是对具体建设工程的,及时提出规划设计条件,同时应向建设单位发出规划设计条件书面通知书。 规划设计条件通知书一般应包括以下内容:1)用地情况；2)用地使用性质；3)用地使用强度(容积率、建筑密度、居住人口毛密度、居住建筑面积毛密度) ；4)建筑设计要求(建筑规模、建筑高度、建筑层数、退规划用地边界线距离、建筑间 距、交通出入口方位、停车数量、绿化) ；5)城市设计要求(体量、高度、材料、色彩等）6)市政要求；7)配套要求；8)其他；9)遵守事项。

1、确定是否被允许通知：要设置某个应用未读信息的提醒方式，首先需要确认该应用是否被允许显示通知。确认方法如下：设置——通知中心——批量管理。

2、打开应用后面的开关：然后在批量管理页面中，找到要确认的应用。如果应用后面的开关是关闭的，请打开该开关。

3、设置通知提醒方式：同样，依次点击“设置”——“通知中心”，进行通知中心页面。

4、开启图标角标提醒：在通知中心中，点击“图标角标”选项，打开“全部”后面的开关，或单独打开指定应用后的开关。

5、开启锁屏通知：在通知中心中，点击“锁屏通知”选项，弹出窗口中选择“显示所有通知”或“隐藏通知内容”，其中前者会显示通知的部分内容，后者不显示通知内容。

6、开启指示灯提醒：在通知中心中，点击“更多通知设置“选项，在打开的新页面中开启“收到通知时指示灯闪烁“开关，收到新信息就会有指示灯提示了。

7、设置多样化通知提醒：你还可以通过开启“智能通知管理”和设置“通知 提示方式”来设置各多样化的通知提醒。

通知是指源自App内部，推送给用户的提示信息，一般包含标题和内容两部分，绝大部分通知均是文字内容。

来源(Source)： 这是APP中生成通知的源头。每个APP根据自己不同的内容体系可以有多个内容池，当系统、其他用户或者用户自己的操作引起内容池变化时便会产生通知。

信息(Information) ：以通知为载体传达给用户的消息。比如说“Jesse申请成为你的好友”或者“James赞了你的推文”。

徽章(Badge) ：引导用户查看通知的视觉元素 。徽章里的指示可以是一个简单的点，也可以展示未读消息的数量。（对于强迫症患者来讲，徽章就是“恶魔”）

锚点(Anchor) ：指的是界面中用来引导用户进入通知的提示位置。简单来说，锚点就是用户看到通知指引或显示徽章的地方。锚点并不一定只能通知来源的地方显示，也可出现在你希望体现有通知的地方。锚点可以用来展示多种来源的通知，当然也可以只展示一类。你可以这样想，来源是信息架构层面的概念，而锚点不过是你可以看到徽章的视觉元素。

通知是App与用户沟通的一种方式，提高用户再次进入App的可能性，增加用户的粘性，同时也有几率唤醒那些沉默用户。因此通知是APP中十分重要的部分。常用的App通知模型主要有以下几种：

一、通知中心式

在这个模型中，将App内所有的通知都放在独立的通知心中里。通知中心可以是一个精致的页面，也可以是一个弹窗，这可以根据需求及使用场景来确定。

无论通知的来源是什么，所有的通知都被锚点到通知中心里，然后再对通知进行导航分类。Medium就是使用这种模型，底部导航中的铃铛图标会出现徽章，从而作为指向所有通知的入口。视觉上区分已读和未读通知变得尤为重要，用户需要清晰地辨别这两类信息。

这种方式的优点在于比较灵活，扩展性较好，通知中心的入口可以根据需要进行调整，后续即便是增加了新的通知类型，只需在通知中心内部调整即可，对其他模块没有影响。

缺点就是众多类型的通知放在一起会略显杂乱，最好用tab加以区分

设计原则：

所有不同类别的通知都需要使用同一种设计模式，而且一定要考虑这种模式的扩展性。

如果你有太多通知来源，可能会出现界面乱糟糟的情况，这时候你就要考虑将同一类的通知合并成一个组，有助于减少信息重复出现。例如：James与2位好友开始关注你。

请确保通知中心的入口容易被发现和触达。

通知中心式适合于：

产品中的通知无法被锚点到任何一个已有的导航中。可能因为通知不和已有内容一致，或现有内容架构中并没有生成通知的来源。

有些来源的通知在已有页面中无法承载。

当时间很紧急，你可能很难把所有可能的通知场景该如何锚点都细想一遍。这种情况下，通知中心是一个很简单的方案，在实际操作中也很灵活。

二、来源锚点式

这种方式中，所有的通知都被锚点到导航的菜单中，这些菜单也正是通知的来源。

APP中并没有一个共有的通知中心。看下WhatsApp的截图会更易理解，无论是安卓还是iOS版本，通知被锚点到了各自的来源——Chats和Calls。

这种方式的优点在于内容极易被发现，凭借通知用户可以非常直接地获取到信息，过程中无需进入额外的中间页。不过这种方式的灵活性和伸缩性不如通知中心式，一旦后续需要调整，可能各个消息来源模块都要改动，工作量会较大。

这种方式高度依靠APP本身的信息架构，导航本身必须可以容纳不同类别的通知，即所有的通知必须有与之对应的来源模块。和上一个模型一样，这里也需要通过视觉设计来区分已读和未读通知。

设计原则：

确保每一个通知可以和导航里的菜单对应起来。随着你APP复杂度的增加，各个通知的来源也随之变多，这个时候你可以考虑使用通知中心或者混合式的模型（把通知中心式和来源锚点式混合起来）。我们将在下一个段落中讲到混合式。

每一个锚点的设计模式应该可以承载各自的内容，并确保你的通知适合这种锚点的设计模式。用WhatsApp举例，锚点“聊天”本身有自己的设计模式定义了每一个聊天应该长成什么样，那关于聊天的通知就必须跟随这个设计模式。“电话”也是同理。

确保每一个锚点都易被发现与触达，尽量避免在子级页面中出现锚点。

来源锚点式适合于：

当所有的通知的来源可以被安置到APP首页（包含主导航）中。

你必须仔细想一遍所有需要通知的场景，且所有的通知可以被安置到现有的设计模型里。通知和来源的设计模式必须保持一致，这一点很重要。

三、混合模式

顾名思义是前两种模式的混合体，且使用最为广泛，Facebook、LinkedIn、 Twitter、Instagram等一些热门APP都在使用它。

例如：Facebook，消息中心变成了主导航中的一个菜单，用来展现哪些无法在主页面中展示锚点的通知。Facebook把好友邀请的通知锚点在了主导航的好友菜单中，而把推荐用户锚点到了通知中心。

这种模型同时具备了前两种模型的优点并且可以适用于大部分情况。虽然你现在可以把所有通知都锚点到通知中心里，但仍有必要仔细考虑一下是不是有些场景的通知更应该优先使用来源锚点式。

设计原则：

定义产品体系中所有的内容池，并按重要等级排序，这样可以帮助你列出哪些通知应该被锚点到来源，哪些可以直接进消息中心。由于这种模型与导航非常相关，通知的配置方式会影响到你导航的设计。

确保主锚点和通知中心易被发现，并且作为主页导航的一部分。

混合式模型适用于：

当你仔细考虑通知的场景后，发现一些通知可以被锚点到对应的来源中，但是有些却找不到已有的来源。

在你的导航体系中，有些来源藏得比较深。举个例子，Facebook导航中有个汉堡包餐单，当他的二级餐单中有通知来源时，汉堡包餐单就会变为锚点，例如：小组、视频、那年今天、收藏夹等。

结论

上述的模型都要用在正确的场景中，根据你APP的信息架构来选择合适的模型，可以让通知发挥更好的效果。

原文链接：https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96

通知是指源自于APP以用户为目标的信息片段，以下是通知的几个重要组成部分：

来源(Source)： 这是APP中生成通知的源头。每个APP根据自己不同的内容体系可以有多个内容池，信息在内容池中进行归类，这些内容池将会变成通知的来源。

信息(Information) ：以通知为载体传达给用户的消息。比如说“Jesse申请成为你的好友”或者“James赞了你的推文”。

类型(Type)： 通知主要分为两类——信息类和操作类。如果你APP需要的话，这两种都可以继续区分子类别。

徽章(Badge) ：引导用户查看通知的视觉元素 。徽章里的指示可以是一个简单的点，也可以展示未读消息的计数。

锚点(Anchor) ：指的是界面中用来引导用户进入通知的提示位置。简单来说，锚点就是用户看到通知指引或徽章的地方。锚点并不一定只能打在通知的来源，也可以打在你希望体现有通知的地方。锚点可以用来展示多种来源的通知，当然也可以只展示一类。你可以这样想，来源是信息架构层面的概念，而锚点不过是你可以看到徽章的视觉元素。

通知是一种媒介，APP使用它与用户沟通，让用户有再次打开APP的可能性。因此通知是APP中十分重要的部分。让我来介绍几种常见的通知模型，并说明为什么它们适合于自己的APP。

在这个模型中，把所有的通知都放在了通知心中里。通知中心可以是一个精致的页面，也可以是一个弹窗，这取决于你的界面设计。

无论通知的来源是什么，所有的通知都被锚点到通知中心里，然后再对通知进行导航分类。Medium就是使用这种模型，底部导航中的铃铛图标会出现徽章，从而作为指向所有通知的入口。视觉上区分已读和未读通知变得尤为重要，用户需要清晰地辨别这两类信息。

这种方式的最大优点在于灵活性，以一含百，即使未来有新的来源出现也可以应对。

设计原则：

通知中心式适合于：

这种方式中，所有的通知都被锚点到导航的菜单中，这些菜单也正是通知的来源。

APP中并没有一个共有的通知中心。看下WhatsApp的截图会更易理解，无论是安卓还是iOS版本，通知被锚点到了各自的来源——Chats和Calls。

这种方式的优点在于内容的易发现性，凭借通知用户可以非常直接地获取到信息，过程中无需进入额外的中间页。不过这种方式的灵活性和伸缩性不如通知中心式。

这种方式高度依靠APP本身的信息架构，导航本身必须可以容纳不同类别的通知。和上一个模型一样，这里也需要通过视觉设计来区分已读和未读通知。

设计原则：

来源锚点式适合于：

顾名思义是前两种模式的混合体，且使用最为广泛，Facebook、LinkedIn、 Twitter、Instagram等一些热门APP都在使用它。

例如：Facebook，消息中心变成了主导航中的一个菜单，用来展现哪些无法在主页面中展示锚点的通知。Facebook把好友邀请的通知锚点在了主导航的好友菜单中，而把推荐用户锚点到了通知中心。

*Facebook目前已更新：

这种模型同时具备了前两种模型的优点并且可以适用于大部分情况。虽然你现在可以把所有通知都锚点到通知中心里，但仍有必要仔细考虑一下是不是有些场景的通知更应该优先使用来源锚点式。

设计原则：

混合式模型适用于：

上述的模型都要用在正确的环境中，根据你APP的信息架构来挑选适合的模型，可以帮助你提供想要的通知类型。

原文作者：Shashank Sahay

原文链接：https://medium.muz.li/designing-notifications-for-applications-3cad56fecf96

翻译：Jesse Zhou

本文由@Jesse Zhou 翻译发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash, 基于CC0协议

应该在通知函上说明设计变更通知内容，必要时附图，并逐条注明应修改图纸的图号，并且图纸变更过多或方案更改过大时应要通知有关部门进行送审，并且要给出相关设计变更费用。

设计变更是指项目自初步设计批准之日起至通过竣工验收正式交付使用之日止，对已批准的初步设计文件、技术设计文件或施工图设计文件所进行的修改、完善、优化等活动。

设计变更应以图纸或设计变更通知单的形式发出。 改变有关工程的施工时间和顺序属于设计变更。变更有关工程价款的报告应由承包人提出。承包人在施工过程中更改施工组织设计的，应经业主和监理同意。

扩展资料

设计变更的原因

1.修改工艺技术，包括设备的改变；

2.增减工程内容；

3.改变使用功能；

4.设计错误、遗漏；

5.提高合理化建议；

6.施工中产生错误；

7.使用的材料品种的改变；

8.工程地质勘察资料不准确而引起的修改，如基础加深。

9.由天气因素导致施工时间的变化；

由于以上原因所提出变更的有可能是建设单位、设计单位、施工单位或监理单位中的任何一个单位，有些则是上述几个单位都会提出。

参考资料：百度百科-设计变更

设计变更应以图纸或设计变更通知单的形式发出。改变有关工程的施工时间和顺序属于设计变更。变更有关工程价款的报告应由承包人提出。承包人在施工过程中更改施工组织设计的，应经业主和监理同意。

原则

设计变更无论是由哪方提出，均应由监理部门会同建设单位、设计单位、施工单位、业主协商，经过确认后由设计部门发出相应图纸或说明，并由监理工程师办理签发手续，下发到有关部门付诸实施。但在审查时应注意以下几点：

1、确属原设计不能保证工程质量要求，设计遗漏和确有错误以及与现场不符无法施工非改不可。

2、一般情况下，即使变更要求可能在技术经济上是合理的，也应全面考虑，将变更以后所产生的效益(质量、工期、造价)与现场变更往往会引起施工单位的索赔等所产生的损失，加以比较，权衡轻重后再做出决定。

3、工程造价增减幅度是否控制在总概算的范围之内，若确需变更但有可能超概算时，更要慎重。

4、设计变更应简要说明变更产生的背景，包括变更产生的提出单位、主要参与人员、时间等。

5、设计变更必须说明变更原因，如工艺改变、工艺要求、设备选型不当，设计者考虑需提高或降低标准、设计漏项、设计失误或其它原因。

6、建设单位对设计图纸的合理修改意见，应在施工之前提出。在施工试车或验收过程中，只要不影响生产，一般不再接受变更要求。

7、施工中发生的材料代用，办理材料代用单。

要坚决杜绝内容不明确的，没有详图或具体使用部位，而只是增加材料用量的变更。

扩展资料

建筑设计变更是指对过去批准的设计文件的修改。设计文件经批准后不得任意修改或变更，但在实践中由于主客观方面的各种原因，有时必须对原定的设计加以修正。

如因基本建设计划修改、地质勘察不够准确、设计文件漏项、工程用料变更、施工条件改变等造成原定设计明显不合理，则须对原设计进行修改。设计变更一般由设计单位提出变更图纸或变更通知单，经有关部门批准后方能生效。

其批准的权限视修改的内容所涉及的范围而定：修改部分涉及计划任务书的主要内容(如建设规模、产品方案、建设地点及主要协作关系)时，须经原计划任务书的审批机关批准；修改部分涉及初步设计的主要内容(如总图布置、工艺流程、设备选型、建筑面积、标准、定员、概算)时，须经原初步设计的审批机关批准；施工图设计的修改，须经原设计单位的同意。

经过批准的设计变更图纸或设计变更通知单应存入技术档案，作为工程施工、交工验收和办理结算的依据。

参考资料来源：百度百科-建筑设计变更

参考资料来源：百度百科-设计变更

看下面这段参与工程建设任何一方提出设计变更申请后，监理单位应根据设计工程变更引起的合同工期、质量、进度、造价等要素进行审查后，提出书面设计变更方案意见交发包人审查同意后，由发包人交由原设计单位提出设计方案及估算，然后由发包人召集财务总监（若设）、财政局、监察局（若需要）等单位人员现场签定、核准变更事项（若单项设计变更引起工程造价增加额在5万元以下的，可由发包人自行研究确定、核准变更事项），经发包人同意后，由原设计单位负责完成具体的设计变更工作，并签发出正式的设计变更通知书（包括施工图纸）。监理单位对设计变更通知书进行核实并经发包人批准后，对承包人下达工程变更令，由承包人组织实施。

好像是监理人

//写的比较简单,如果要进行多条录入的话,就把指针改成指针数组就可以

#include <iostream>

#include <string>

using namespace std

struct data

{

int year,month,day,hour,minute

void print()

{

cout<<year<<"年"<<month<<"月"<<day<<"日"<<hour<<"时"<<minute<<"分"<<endl

}

}

class information

{

public:

information(int year=0,int month=0,int day=0,int hour=0,int minute=0)

{

dt.year=year,dt.month=month,dt.day=day,dt.hour=hour,dt.minute=minute

}

~information()

{

delete []p

}

void input(char arr[]=NULL)

{

p=new char[sizeof(arr)+1]

strcpy(p,arr)

}

void print()

{

dt.print()

cout<<"通知:"<<p<<endl

}

private:

data dt

char *p

}

int main()

{

information ion(2006,11,29,5,30)

ion.input("开会")

ion.print()

}