Line 84: Line 84:
--[[User:Gcoulombe|Guillaume Coulombe]] ([[User talk:Gcoulombe|talk]]) 07:14, 23 April 2015 (PDT)
--[[User:Gcoulombe|Guillaume Coulombe]] ([[User talk:Gcoulombe|talk]]) 07:14, 23 April 2015 (PDT)


:Thank you for all that work.
:* Excellent point about ''Affiliated Institution''. So, if a project is made with a University, but for a school in Sierra Leonne, does it have 2 affiliated institutions?
:* A distinction between ''Design'' pages and ''Projects'' pages: Good point, and I agree that in many pages this distinction is not clear, and/or they are in the wrong category. I'd like to get Lonny's & Joshua's thoughts.
:--[[User:Chriswaterguy|Chriswaterguy]] ([[User talk:Chriswaterguy|talk]]) 15:10, 27 April 2015 (PDT)


===April 22nd, 2015===
===April 22nd, 2015===

Revision as of 22:10, 27 April 2015

Development follow up

April 24th, 2015 : analysing morning

OSAT Designs vs Projects

Brain runs, going through project files submited along the site development/structure. It seems more and more appropriate that the projects category pages shall be distinct from the Designs Pages. A semantic relation established between the two would interconnect the pages that are closely related and a link to the complete documentation file (as on EWB website) could also be accessible from both pages.

As there is a FormInput box in the EWB Challenge page to create pages that are automatically linked to the EWB Challenge, it would be feasible to create Design Pages that would have the same kind of link. A semantic property of Page type, in the Project page, called something like "Has Designed Deliverable" would indicate that the Project lead to the design of one or more Designs. It's what happened in the case of the Water filter for 4A_Water Purtification Module, where to majors designs were made : one for the water filter, and one for the stove. This way, by splitting the Project documentation in 3 different pages linked by the semantics, we would make the global content of the documentation of the project be more exposed, and attained in different ways, by clearer pages categorization on one side, as well as having clearer pages by themselves, structured to expose clearly the info as Design Pages to describe the what(s) and Projects Pages to describe the Context of the Designs.

Status:Concept

Also, I gave more thoughts to the Appropedia:Status structure. I do think the taxonomy is very clear and succint! And also appropriate to the Design Pages concept I expose my thinking around. I do understand that the EWB Challenge Projects are clearly made to produce what we call here a good Status:Design, and that the new proposed status, Concept, would not be as clear as the rest of taxonomy. It has to many other significations that can be relevant in Appropedia (like the concept of 3d printing, the concept of Open Source...) that I would prefer Design Idea, or Design Concept or Design in progess or something like that, expressing the draftness. But still, I would not necessarily add a new status right away! Maybe we explain to the contestants and other users that when they are Done and Proud, then they can add the Status:Design?

Also, the proposed taxonomy is initially made for something that is more the design of something reproducible, as a machine, a device, or a construction. But for the description of a project, I do not feel it's that appropriate, specially in a project where the deliverable is a design. It would be quite not that useful to toggle it between status #1, and eventually #2! And I also do not see it feasible that someone else than from the starting team, would lead the former project page to setp #3 and 4 and so on... Because the projects page will not be relevant anymore : other team leaders, other affiliations...

So maybe describing projects with a taxonomy more related to projects could be clearer? Using simply a Project Managements Processes], then we would be at ease to clearly identify projects related to designs, and if the projects are still on going, as opposed to actually, where when I browse the projects, I do not see easily if people are still putting efforts in a project.

So the more I write and the more I think I have to go this way! By example, if I was to lead a team taking a Design made by a EWB team to create a prototype, then I would create a new project associated with the Design pages they made : we would see both projects in the Design page in a template that would query for Projects associated with the Design. And I would have clicked a button Create a project around this design in the page of the design to start my Projects documentation...

So for the affiliations

My thinking on the idea of changing the Has Project Type to Has Affiliation, and Host University. Well, there would be more flexibility and precision possible to keep Has Project Type like this. EWB Challenge Project or Personal Project or Classroom 124W Project, are examples.

Using the term Affiliation would be good, but in another field. By looking back this morning in the files Chris sent me, the first line of 2B Water Filtration Timor Leste jumped to my face : Engineers Without Borders (EWB) is working with Plan Timor-Leste (Plan TL).... Here I see 2 affiliations to the project : EWB and Plan TL. If we would eventually have a Plan TL page on Appropedia, it would be easier to query on projects where they are affiliated and ask to show the Project Type property of each project in the results than to query on EWB Challenge projects, and other possible Project Type-Affiliation where they would be. The same way, if we have a EWB Page (generic to the .org and not the Challenge, than it will be easier to get a list of all projects affiliated with them by putting EWB in Affiliated semantic property and give relevant info to show Project Type as well (where we would see EWB Challenge and others).

So for Affiliation precision and clear and easy contextualisation, I would strongly recommend to keep Single Value Project Type where people can add new values but being asked to be clear.

I would also probably create 4 Affiliation properties : Affiliated School, Affiliated Non-Profit (for NGOs, churches, not-for-profit corporations, foundations and cooperatives and others), Affiliated Government and Affiliated For-Profit (for for-profit corporations, cooperatives and others). What is your thoughts on this one?

... And on the rest?

I still have around 10 hours to go. I got a little late on schedule, not this week but the one before, but it is feasible for me to create a Design Description and form as I suggest here, plus adapt the Project Description models and forms to work in relation between both Designs and Projects. I will not adapt the actual Projects Pages to this work for now, but I will set the EWB Challenge projects working well on this proposal, and I do believe that it will be top class!!

Yours, --Guillaume Coulombe (talk) 10:47, 24 April 2015 (PDT)

April 23rd, 2015 (pm)

Thanks for the follow up!

Yesterday, I was wanting to exchange with you about the Projects Category use in Appropedia before setting form in there... But I forgot to save this talk page after previewing it!

So here is my comment from yesterday :

Development Decision about the use of the Projects Category: I'm pretty sure it would improve the Project aspect of Appropedia; at the same time, as a project normally does have a start and an end, it would be important projects are treated this way in Appropedia.

I will explain this with this example : 3-D_printable_solar_charger, which is now categorized under Projects (along other categories). At the same time, this page expresses more the design of the Solar Charger than the project realized to create it.

My "semantics" thinking of this case, which is similar to many others in Appropedia's Projects Category, is that there would preferably be a distinction between Design pages and Projects pages, having links between each other. One for the context, one for the Results documentation. In our 3d printed charger, we would then have a page called Designing a 3d printable solar charger for Emergency Lightning (or something like this) as a Project Page, explaining what drove who to this efforts, and then the 3d printable solar charger Page, explaining how to reproduce the system. It would then get more easy to design wiki pages for Designs, and others for Constructions, still being able to document both their realization in similar Projects pages.

Because of this questionning on the use of the Projects Category, for today, I did add the Has default form property (for form edit) on Category:EWB Challenge Projects page. I also added a Forminput for projects creation on the new EWB Challenge presentation page. This forminput automatically affiliates EWB Challenge to the created projects when used. I also set the Category EWB Challenge Projects to projects with this affiliation with the #set parser function in the template.

When decided, It will be pretty simple to move the Has default form from the EWB Challenge Projects Category page to the Projects Category page, whenever we are ready to make all projects editable with form. Note that a page cannot be edited by 2 different forms, so the semantic property Has default form should normally be added to only one category.

Follow up on you other comments from yesterday:

  • There is no option to edit with form : The [[Has default form::]] property had to be set in a category's Page in order to edit the pages automatically.
It's done!
Now it does! It was the intention but I forgot that Combobox input form only allows one entry.
  • Can we add a photo like it is in the medical devices?
Yes... And done! Note that the Caption does not work in Medical Device. The pictures which are Frameless do not show any caption. For so, the Template:Medical Device image parameter would have to be changed from frameless to frame Mediawiki Help Image.

The NOT treated comments yet :

  • Let's change:
    • "Project Type" to "Affiliation"
    • "Affiliated University/Institution" to "Host University/Institution". (We can choose the exact wording later. "Host University/School/Institution/Program" seems too long. "Host Institution/Program"?)
      • I'd personnaly only write Affiliated organization or something generic that will be possibly including corporations... This is why I gave the semantic property name Affiliated Institution.
      • For the Host wording of the property - Host University instead of Affiliated - if a project is made with a University, but for a school in Sierra Leonne, by example, I thought the Sierra Leonne School would be the host of the project... What do you think?
  • Re Status: I *think* this could be a radio style input, but we have asked for confirmation from Pr Joshua Pearce (the major user of status tags). We'll let you know.
    • Thinking in progress...

--Guillaume Coulombe (talk) 07:14, 23 April 2015 (PDT)

Thank you for all that work.
  • Excellent point about Affiliated Institution. So, if a project is made with a University, but for a school in Sierra Leonne, does it have 2 affiliated institutions?
  • A distinction between Design pages and Projects pages: Good point, and I agree that in many pages this distinction is not clear, and/or they are in the wrong category. I'd like to get Lonny's & Joshua's thoughts.
--Chriswaterguy (talk) 15:10, 27 April 2015 (PDT)

April 22nd, 2015

Things are going well! You can see the Project Description Template in action here :

Both projects look the same. The difference is that one have a few less Semantic properties. I made the Affiliated University / Institution text disappear when not used, because it would be very normal that a project would not be affiliated with one of these.

In order to understand the development orientations, I invite you to read the Template Description page, along all the Semantic properties pages (see Project Description Test 1 facts box in the bottom of the page for a link for each properties.

Note : I saw there are Templates description Templates used in Appropedia, although using sub pages for this is new to me. I need a little help getting me started and then I will normalize my Template and Semantic Properties documentation.

Next steps would be :

  • Associate the Category:Projects with Form:Project Description, adding the semantic property [[Has default form::Project Description]] to the Category page.
  • Develop MediaWiki:Project Description form preload, as MediaWiki:Medical Device form preload; Lonny or Chris, I will need you to create the page when I'm done because it is in Mediawiki: Namespace and I am not allowed to write there. There is also some kind of autofill to pages created with the Form Edit field in the Projects Category page. We could probably use this?
  • Create EWB Challenge Project generic page, with queries on the EWB Challenge Project Project type
  • Automatically set the Category Projects to the pages created with the form, as well as the EWB Challenge Project Category to the ones with this type. It will look like this : Sanitation and [[Category:Sanitation]]
  • Review other details from the Appropedia:EWB Challenge site development/Structure page.


Thanks Guillaume, this looks great!
(Thank you!)
  • "I saw there are Templates description Templates used in Appropedia, although using sub pages for this is new to me."
  • This would be the work of some Wikipedian editors, copying the way they do it there. You do not need to do this - I usually don't do it, and Lonny and I find it a bit confusing too. So I think it's okay to do the simplest thing that works :-).
  • You are now an admin and can edit the "MediaWiki" namespace.
  • In Project Description Test 1, there is no option to edit with form. Lonny & I don't know why that happens. E.g. see IStethoscope, there is "edit" (which is edit with form) and "edit source".
  • Can we add a photo like it is in the medical devices?
  • Let's change:
    • "Project Type" to "Affiliation"
    • "Affiliated University/Institution" to "Host University/Institution". (We can choose the exact wording later. "Host University/School/Institution/Program" seems too long. "Host Institution/Program"?)
  • Re Status: I *think* this could be a radio style input, but we have asked for confirmation from Pr Joshua Pearce (the major user of status tags). We'll let you know. --Chriswaterguy (talk) 18:42, 22 April 2015 (PDT)

April 20th, 2015

--Guillaume Coulombe (talk) 14:24, 20 April 2015 (PDT)


April 15, 2015

It did start the prototyping of the semantics for EWB Projects in Appropedia. I did these developments on a wiki on my side. The look is a bit different, but the wiki code will be pretty much the same. It is only the <div> encodings that could change a bit. Nothing that make us work more.

I would like input on 2 questions :

  1. Please give me your preference for the Look and feel of the Form: I did develop 2 models, one that is more Questionnaire style, one that is more Table type. Which one do you prefer? My favorite is the Questionnaire, but may be you want something more succint. Note : I'm still at prototype : English will get better ;-) - as well, data fields will be activated with the creation of the Semantic Properties pages, which I will only do on Appropedia site : this is why the answers are in redlink and the form reacting a bit so-so.
  2. On another hand, if you look at the semantic properties listed in this page, It is feasible to treat the Model to develop as something a bit more generic than EWB. Of course, I do not suggest to do a global project management ontology, but to treat EWB Challenge project as a Project Type. This way, with this Example page, instead of writing in the Model EWB Challenge Project, I would put the semantic property "Has type" in the header and EWB Challenge Project would appear as well. As for the other properties, they could be quite generic, as Affiliated University would be my suggestion for EWB Challenge University, which is something that happens in different project. That way, we could query different or unique Types of project, to filter all projects affiliated with an institution, or only the EWB Challenge Project. My suggestion is to go generic, as it will be more flexible and adaptative and easier to put a form for a generic category than just a specific.

--Guillaume Coulombe (talk) 12:41, 15 April 2015 (PDT)

Thanks Guillaume, this looks good.
Re the 2 models, I like both.
I think your idea (treating EWB Challenge project as a Project Type) makes good sense.
That's my initial impression - I will look in more detail later at the required fields/data. Thank you! --Chriswaterguy (talk) 19:54, 15 April 2015 (PDT)
Cookies help us deliver our services. By using our services, you agree to our use of cookies.