Connexions - Revision history

Marcin at 04:02, 1 April 2012

2012-04-01T04:02:06Z

← Older revision		Revision as of 04:02, 1 April 2012
Line 7:		Line 7:
	<html>		<html>
	<iframe width="560" height="315" src="https://www.youtube.com/embed//nOExdnESMkY" frameborder="0" allowfullscreen></iframe>		<iframe width="560" height="315" src="https://www.youtube.com/embed//nOExdnESMkY" frameborder="0" allowfullscreen></iframe>
			<object width="398" height="374">
	<param name="movie" value="http://video.ted.com/assets/player/swf/EmbedPlayer.swf"></param>		<param name="movie" value="http://video.ted.com/assets/player/swf/EmbedPlayer.swf"></param>
			<param name="allowFullScreen" value="true" />
			<param name="allowScriptAccess" value="always"/>
			<param name="wmode" value="transparent"></param>
			<param name="bgColor" value="#ffffff"></param>
			<param name="flashvars" value="vu=http://video.ted.com/talk/stream/2006/Blank/RichardBaraniuk_2006-320k.mp4&su=http://images.ted.com/images/ted/tedindex/embed-posters/RichardBaraniuk-2006.embed_thumbnail.jpg&vw=384&vh=288&ap=0&ti=25&lang=&introDuration=15330&adDuration=4000&postAdDuration=830&adKeys=talk=richard_baraniuk_on_open_source_learning;year=2006;theme=the_rise_of_collaboration;theme=how_we_learn;theme=what_s_next_in_tech;theme=tales_of_invention;event=TED2006;tag=business;tag=collaboration;tag=culture;tag=education;tag=global+issues;tag=library;tag=open-source;tag=technology;tag=web;&preAdTag=tconf.ted/embed;tile=1;sz=512x288;" />
			<embed src="http://video.ted.com/assets/player/swf/EmbedPlayer.swf" pluginspace="http://www.macromedia.com/go/getflashplayer" type="application/x-shockwave-flash" wmode="transparent" bgColor="#ffffff" width="398" height="374" allowFullScreen="true" allowScriptAccess="always" flashvars="vu=http://video.ted.com/talk/stream/2006/Blank/RichardBaraniuk_2006-320k.mp4&su=http://images.ted.com/images/ted/tedindex/embed-posters/RichardBaraniuk-2006.embed_thumbnail.jpg&vw=384&vh=288&ap=0&ti=25&lang=&introDuration=15330&adDuration=4000&postAdDuration=830&adKeys=talk=richard_baraniuk_on_open_source_learning;year=2006;theme=the_rise_of_collaboration;theme=how_we_learn;theme=what_s_next_in_tech;theme=tales_of_invention;event=TED2006;tag=business;tag=collaboration;tag=culture;tag=education;tag=global+issues;tag=library;tag=open-source;tag=technology;tag=web;&preAdTag=tconf.ted/embed;tile=1;sz=512x288;"></embed>
			</object>
	</html>		</html>
	=Notes=		=Notes=

Marcin at 04:01, 1 April 2012

2012-04-01T04:01:34Z

← Older revision		Revision as of 04:01, 1 April 2012
Line 7:		Line 7:
	<html>		<html>
	<iframe width="560" height="315" src="https://www.youtube.com/embed//nOExdnESMkY" frameborder="0" allowfullscreen></iframe>		<iframe width="560" height="315" src="https://www.youtube.com/embed//nOExdnESMkY" frameborder="0" allowfullscreen></iframe>
			<param name="movie" value="http://video.ted.com/assets/player/swf/EmbedPlayer.swf"></param>
	</html>		</html>
	=Notes=		=Notes=

Sigmund Petersen: /* Notes */

2012-03-30T11:04:36Z

Notes

← Older revision		Revision as of 11:04, 30 March 2012
Line 12:		Line 12:
	Connexions provides modules and collections. Modules need to be stand-alone concepts; collections need to be a sequence of modules.		Connexions provides modules and collections. Modules need to be stand-alone concepts; collections need to be a sequence of modules.

	The [[Distributed_Collaboration]] structure starts with Definitions, which are then combined into Projects, which are then embellished and published as Reports.		The [[Distributed_Collaboration \| Distributed Collaboration]] structure starts with Definitions, which are then combined into Projects, which are then embellished and published as Reports.

	Maybe create a module for each self-evident definition, no matter how small. Connexions doesn't include any way to manage a project, so that has to happen outside of their service. As the Definition modules are created, they get combined into a project file. That project file then becomes its own module (or set of modules?). Finally, additional modules would be created for things like Overview, and Introduction, and BOM. After all that is done a collection would bring everything together to define one machine.		Maybe create a module for each self-evident definition, no matter how small. Connexions doesn't include any way to manage a project, so that has to happen outside of their service. As the Definition modules are created, they get combined into a project file. That project file then becomes its own module (or set of modules?). Finally, additional modules would be created for things like Overview, and Introduction, and BOM. After all that is done a collection would bring everything together to define one machine.

	=Instructions=		=Instructions=
	<html><iframe width="420" height="315" src="https://www.youtube.com/embed//TzeXAVpvg-I" frameborder="0" allowfullscreen></iframe></html>		<html><iframe width="420" height="315" src="https://www.youtube.com/embed//TzeXAVpvg-I" frameborder="0" allowfullscreen></iframe></html>

Marcin at 03:54, 30 March 2012

2012-03-30T03:54:09Z

← Older revision		Revision as of 03:54, 30 March 2012
Line 15:		Line 15:

	Maybe create a module for each self-evident definition, no matter how small. Connexions doesn't include any way to manage a project, so that has to happen outside of their service. As the Definition modules are created, they get combined into a project file. That project file then becomes its own module (or set of modules?). Finally, additional modules would be created for things like Overview, and Introduction, and BOM. After all that is done a collection would bring everything together to define one machine.		Maybe create a module for each self-evident definition, no matter how small. Connexions doesn't include any way to manage a project, so that has to happen outside of their service. As the Definition modules are created, they get combined into a project file. That project file then becomes its own module (or set of modules?). Finally, additional modules would be created for things like Overview, and Introduction, and BOM. After all that is done a collection would bring everything together to define one machine.
			=Instructions=
			<html><iframe width="420" height="315" src="https://www.youtube.com/embed//TzeXAVpvg-I" frameborder="0" allowfullscreen></iframe></html>
	=How To Tag/Name Modules=		=How To Tag/Name Modules=

Marcin at 03:52, 30 March 2012

2012-03-30T03:52:25Z

← Older revision		Revision as of 03:52, 30 March 2012
Line 3:		Line 3:
	http://cnx.org/		http://cnx.org/

			http://www.youtube.com/cnxorg

	<html>		<html>

Marcin at 03:51, 30 March 2012

2012-03-30T03:51:13Z

← Older revision		Revision as of 03:51, 30 March 2012
Line 3:		Line 3:
	http://cnx.org/		http://cnx.org/


			<html>
			<iframe width="560" height="315" src="https://www.youtube.com/embed//nOExdnESMkY" frameborder="0" allowfullscreen></iframe>
			</html>
	=Notes=		=Notes=

Matt Maier at 22:17, 25 March 2012

2012-03-25T22:17:21Z

← Older revision		Revision as of 22:17, 25 March 2012
Line 30:		Line 30:
	Actuator (controls the movement of the machine's mechanisms)		Actuator (controls the movement of the machine's mechanisms)
	Hardware (a small piece of the machine that doesn't fit into any other category)		Hardware (a small piece of the machine that doesn't fit into any other category)

			==KISS==

			These are all prototypes. The way they're named will most likely change no matter how good it is right now. So, just define a simple way to lend some consistency and self-evidentness to the information for right now. The names don't need to be self-evident in an objective sense, just in terms of the GVCS project itself. The only people even working with them will be dedicated developers. We can worry about 8-th grade level communication when we write the report.

			So, the title should be:
			Something very specific within the context of the machine itself.

			The keywords should be:
			Anything else that seems relevant, whether more or less specific.

			We'll take advantage of the fact that GVCS machines are designed to be as simple as possible. Even if there is some small amount of confusion in naming convention that simplicity will make the confusion easy to resolve. As long as the confusion isn't a show-stopper within the instructions for the one specific machine it will be fine.

Matt Maier: /* How To Tag/Name Modules */

2012-03-25T22:11:48Z

How To Tag/Name Modules

← Older revision		Revision as of 22:11, 25 March 2012
Line 23:		Line 23:

	Connexions allows a title and keywords. It makes sense to keep the title short, and add bulk to the keywords. Also, the title should be the part that is least likely to change, hence the most specific name possible.		Connexions allows a title and keywords. It makes sense to keep the title short, and add bulk to the keywords. Also, the title should be the part that is least likely to change, hence the most specific name possible.

			Machine:
			Structure (keeps parts of the machine from moving in relation to each other)
			Mount (holds something in place, but is primarily intended to be a reconfigurable interface rather than part of the structure)
			Mechanism (allows parts of the machine to move in a controlled way in relation to each other)
			Actuator (controls the movement of the machine's mechanisms)
			Hardware (a small piece of the machine that doesn't fit into any other category)

Matt Maier: /* How To Tag/Name Modules */

2012-03-25T21:56:21Z

How To Tag/Name Modules

← Older revision		Revision as of 21:56, 25 March 2012
Line 21:		Line 21:
	* That tells us how to distinguish the machine it belongs to from all other machines, now we need to know how to distinguish the part from all the other parts of that machine. Maybe define it based on what the part itself is and leave the subsystem definition for the project stage. That way if someone wants to use a bearing (or whatever) they don't have to worry about calling by the subsystem name of a different machine.		* That tells us how to distinguish the machine it belongs to from all other machines, now we need to know how to distinguish the part from all the other parts of that machine. Maybe define it based on what the part itself is and leave the subsystem definition for the project stage. That way if someone wants to use a bearing (or whatever) they don't have to worry about calling by the subsystem name of a different machine.
	* Actually, maybe it would be better to leave the machine definition for later and instead just define the part by the attributes it has in isolation. Start most specific, first, then build up to least specific last.		* Actually, maybe it would be better to leave the machine definition for later and instead just define the part by the attributes it has in isolation. Start most specific, first, then build up to least specific last.
	&
			Connexions allows a title and keywords. It makes sense to keep the title short, and add bulk to the keywords. Also, the title should be the part that is least likely to change, hence the most specific name possible.

Matt Maier at 21:52, 25 March 2012

2012-03-25T21:52:17Z

← Older revision		Revision as of 21:52, 25 March 2012
Line 2:		Line 2:

	http://cnx.org/		http://cnx.org/

			=Notes=

			Connexions provides modules and collections. Modules need to be stand-alone concepts; collections need to be a sequence of modules.

			The [[Distributed_Collaboration]] structure starts with Definitions, which are then combined into Projects, which are then embellished and published as Reports.

			Maybe create a module for each self-evident definition, no matter how small. Connexions doesn't include any way to manage a project, so that has to happen outside of their service. As the Definition modules are created, they get combined into a project file. That project file then becomes its own module (or set of modules?). Finally, additional modules would be created for things like Overview, and Introduction, and BOM. After all that is done a collection would bring everything together to define one machine.

			=How To Tag/Name Modules=

			* Date of last edit
			* Instruction language
			* Key words in levels of specificity
			** A word/phrase that clearly distinguishes the type of machine (tractor) TYPE
			** A word/phrase that clearly distinguishes the previous level from all other things with the same type name (LifeTrac) NAME
			** A word/phrase that clearly distinguishes the previous level from all other things with the same model name (Version 4) VERSION
			* That tells us how to distinguish the machine it belongs to from all other machines, now we need to know how to distinguish the part from all the other parts of that machine. Maybe define it based on what the part itself is and leave the subsystem definition for the project stage. That way if someone wants to use a bearing (or whatever) they don't have to worry about calling by the subsystem name of a different machine.
			* Actually, maybe it would be better to leave the machine definition for later and instead just define the part by the attributes it has in isolation. Start most specific, first, then build up to least specific last.
			&