Web Developers - WikiHouse.cc needs you!

[Alastair]

Hi All - 

As I'm sure you've spotted, wikihouse.cc is long overdue an upgrade, and as development on the hardware side of WikiHouse really begins to accelerate, and the governance / constitution taking hard form, it's the website that is becoming more and more a barrier to growing the community and the project (not least being stuck in google groups!). With previous contributors all dedicated onto other full-time projects, we badly need a web developer, or team of web developers  to help us build the next version of wikihouse.cc : a genuinely useful, easy-to-use design commons and community platform.

We've developed an initial outline set of goals / design, but we'd love to work with one (or possibly more) web developers who are interested in making it happen. We know there are some talented developers already in this community who have expressed an interest in collaborating, so we just thought we'd just... ask, and see if anyone can help.

What?

We're currently using html, css, javascript, python - and alongside that there's the sketchup plugin which the Espians wrote in Ruby.

Basic aims are:

1. Develop the clean visual layer of the site, which is based on bootstrap. If there's sufficient load on javascript to warrant it, we could probably look to use react.js (@thruflo is the guy-in-the-know here, who will support).

2. Build one or a number of core site modules that sit within the site, such as:

- A new front news page.

- A clean, easy to use, design library page structure for open sharing of design files and documentation, licensing and T&Cs (possibly drawing off github repo) - ie. The next bite at a wikipedia page structure for hardware.

- A live community collaboration space (possibly using something like Loomio).

- A map / directory of WikiHouse chapters and projects.

- A marketplace for teams selling kits / design services using WikiHouse.

- A governance page for discussion with links to core documents such as legals, constitution etc. (again, possibly using Loomio)

- Embeds of the first 'parametric' design apps.

- (Insert other module ideas here!)

Just by way of indication of design intent, attached is a pdf mockup of some of that.

3. We're particularly asking to see if there's one person in particular interested in acting as a co/ordinator / host for that effort. That's an ongoing need, so that anyone can take on specific modules and contribute to the website now and in the future.

Where?

It would be fantastic if there was someone who could hang out with us some or all of the time in London, but working mostly via skype is also a possibility.

Funding

This is just a call for volunteers to help build, WikiHouse Foundation doesn't yet have the funding to support any paid roles, but if there is someone really interested in taking this on, what 00 can offer is a desk space in a cool central London hub (link), and hope shortly to be able to land chunks of funding to support someone's time. 

If you're interested, or you know someone who might be, please do pass this on, drop a public reply below, or drop us an email. he...@wikihouse.cc

Huge love and thanks to everyone.

Alastair 

[Martin Luff]

Hi Alastair - posting this here rather than trapping another thing in our inboxes ;)

Seems like this is part of the wider 'platform' debate?

As a number of the people in the WikiHouse project have already discovered, the original WikiHouse CC site always had a few issues around uploading and sharing files (no criticism of those who put in sterling work creating this much needed resource since not easy to also create robust file sharing and so on when we barely even knew our requirements). Plus, judging by traffic here, I'm not the only one who's not a great fan of Google Groups as discussion and idea/file sharing platform; and we're still seeing a lot of files buried in individual email or Skype/Hangouts correspondence between teams and users.

As some of you know, the NZ team are pursuing a number of ideas this end for something that works to support our team here - but always with half an eye on how this might translate to better platform for whole global project. This includes the work with MatterMachine (cloud based industrial grade fully parametric 3D design tool with capacity for both casual user and expert interfaces) alongside some stuff in Rhino 3D and Grasshopper in terms of trying to get more friendly tools that could possibly have interface for untrained users to get far more engaged in design. Alongside this we've spent considerable time trying to find a combo of tools to support dynamic collaborative editing of key documents, project and task management plus discussion, decision making and so on.

Part of my background is both a project manager and web designer/dev so hopefully I've brought a little from both of those to try and craft a solution. 

The NZ team identified a number of key requirements and first attempts were to use something of an 'all in one' approach using Podio at the centre; allied to Google Drive, Google Docs, Evernote and Dropbox. For various reasons this didn't work out. For a while we used Trello for the task management aspects at least - but, although excellent in many respects, we outgrew this as the team became bigger and the full complexity of the WikiHouseNZ/SCS project started to unfold. Recently we looked at how a hybrid approach learning from past projects and partner organisations might look - but it includes an awful lot of tools (see attached diagram). Possible to implement for our relatively tech-savvy team and perhaps not too daunting for a new generation used to a hundred-and-one apps on their mobile - but not so easy for a broader slice of society. 

Plus there's some parts still missing or barely covered. Most notably some good way of us having file versioning (and potentially locking) for CAD collaboration. Which brings me onto my most recent bit of digging around since we've been struggling as a team from day one to collaborate with our distrributed team on CAD file sharing along with maintaining collaborative up-to-date documentation to sit alongside. 

Wider issues are summed up quite nicely in this Wired article from a while back. Obviously we're not going to jump all that way in one go - but might be worth at least holding as long-term vision. Certainly one of the long-term visions for MatterMachine development might be that their text-based open CAD file format might eventually permit the sort of branching and merging and version control common in open software development - but in meantime we'll probably need something to handle binary files (which may be chunky which is why systems like Git, SVN and Mercurial are likely to prove problematic). Anyway, I followed up a couple of links from that article including the one for Open Design Engine (see also the ODE project website) which resulted in some useful looking plugins for Redmine (Ruby on Rails bug tracking and project management tool which I'm not familiar with but seems to have a number of users and fans) including DMSF - Document Management System Features (full list of features at linked page). Plus of course Redmine itself has various ready-made modules like a Wiki and so on plus further down line we can host ourselves or there are various hosted solutions available. Would be helpful if anyone here has had experience on Redmine and wanted to comment on their experience... I set up a quick test installation of Redmine at this end - but big backlog in my 'to-do' list might mean I don't get much time to take a close look in near future.

So a rather roundabout way to come to my main question - which is if we can get together some funds to develop the platform then rather than reinvent the wheel so to speak would it make more sense to help develop a part-made solution like this which seems at least some way there already?

Anyway, a few ideas to throw into mix...

Hopefully more helpful than further muddying the waters.

Kind regards

Martin

[buzz]

hi martin, I'm a bit of a lurker her..... but I have the answer to your version control issue/s. You're probably not going to like it, but don't dismiss it without a long hard think.

1 - strict enforcement that all CAD/design/development be done with tool/s that have a nominally human-readable source format.    This doesn't matter if it's .xml, .scad, etc, but this step *does* positively matter. 
2 - strict enforcement that all contributors agree to item 1, and agree to use the same toolset.   Contributions are useless unless you can compare them to previous work, later work, and other branch work, and merge them.

3 - put these files in version control made for software/files ( eg, git, or svn ).

When it comes time to compare two file/s to see ( for example) which is better,  or what's been changed, you then can start with your graphical toolset, but to be absolutely sure what's changed, you can "view the source"  ( ie look at the xml, or .scad. or whatever). and "diff" the changes with normal source-code-management  tools, which trivially highlights even the tiniest of  changes.

Buzz.

 

[Martin Luff]

Hi Buzz - thanks for that. Nothing wrong with lurking - do a fair bit of that myself ;) 

In principle I can see where you're coming from and I think long-term we'll get there eventually. In meantime I'm not aware of CAD package that would meet our requirements (in particular first-class modelling, 'industrial' quality and with capacity to be fully-parametric). Not to mention some certainty that it has a solid future - not likely to disappear a couple of years down the line. Open Source equivalent to Rhino 3D plus Grasshopper would be good starting point. So not so much I don't like your suggestion but not sure how we'd go about implementing that at this point...

Definitely open for suggestions of tools to take a look at - and quite possible I've missed something in my searching so far.  

Hey, thanks for coming out of the shadows :)

Kind regards

Martin

[buzz]

>
> In principle I can see where you're coming from and I think long-term we'll get there eventually. In meantime I'm not aware of CAD package that would meet our requirements (in particular first-class modelling, 'industrial' quality and with capacity to be fully-parametric).

Personally... having looked at the wiki house stuff only a little. .. I'd start with the quite mature tool openscad... which is fully parametric and files are textual.. but also lacks an advanced gui. It's a simple process of "change some code" then "compile" to see the modified 3d object.

I might also look at FreeCAD ... but I don't know much about that one...

>
> Definitely open for suggestions of tools to take a look at - and quite possible I've missed something in my searching so far.  

>
> Hey, thanks for coming out of the shadows :)
>
> Kind regards
>
> Martin
>
>
> On Tuesday, 29 July 2014 18:54:19 UTC+12, David Buzz wrote:
>>
>> hi martin, I'm a bit of a lurker her..... but I have the answer to your version control issue/s. You're probably not going to like it, but don't dismiss it without a long hard think.
>>
>> 1 - strict enforcement that all CAD/design/development be done with tool/s that have a nominally human-readable source format.    This doesn't matter if it's .xml, .scad, etc, but this step *does* positively matter. 
>> 2 - strict enforcement that all contributors agree to item 1, and agree to use the same toolset.   Contributions are useless unless you can compare them to previous work, later work, and other branch work, and merge them.
>> 3 - put these files in version control made for software/files ( eg, git, or svn ).
>>
>> When it comes time to compare two file/s to see ( for example) which is better,  or what's been changed, you then can start with your graphical toolset, but to be absolutely sure what's changed, you can "view the source"  ( ie look at the xml, or .scad. or whatever). and "diff" the changes with normal source-code-management  tools, which trivially highlights even the tiniest of  changes.
>>
>> Buzz.
>>  
>>
>>
>>
>> On 29 July 2014 15:24, Martin Luff <mar...@merename.com> wrote:
>>>
>>> Hi Alastair - posting this here rather than trapping another thing in our inboxes ;)
>>>
>>> Seems like this is part of the wider 'platform' debate?
>>>
>>> As a number of the people in the WikiHouse project have already discovered, the original WikiHouse CC site always had a few issues around uploading and sharing files (no criticism of those who put in sterling work creating this much needed resource since not easy to also create robust file sharing and so on when we barely even knew our requirements). Plus, judging by traffic here, I'm not the only one who's not a great fan of Google Groups as discussion and idea/file sharing platform; and we're still seeing a lot of files buried in individual email or Skype/Hangouts correspondence between teams and users.
>>>
>>> As some of you know, the NZ team are pursuing a number of ideas this end for something that works to support our team here - but always with half an eye on how this might translate to better platform for whole global project. This includes the work with MatterMachine (cloud based industrial grade fully parametric 3D design tool with capacity for both casual user and expert interfaces) alongside some stuff in Rhino 3D and Grasshopper in terms of trying to get more friendly tools that could possibly have interface for untrained users to get far more engaged in design. Alongside this we've spent considerable time trying to find a combo of tools to support dynamic collaborative editing of key documents, project and task management plus discussion, decision making and so on.
>>>
>>> Part of my background is both a project manager and web designer/dev so hopefully I've brought a little from both of those to try and craft a solution. 
>>>
>>> The NZ team identified a number of key requirements and first attempts were to use something of an 'all in one' approach using Podio at the centre; allied to Google Drive, Google Docs, Evernote and Dropbox. For various reasons this didn't work out. For a while we used Trello for the task management aspects at least - but, although excellent in many respects, we outgrew this as the team became bigger and the full complexity of the WikiHouseNZ/SCS project started to unfold. Recently we looked at how a hybrid approach learning from past projects and partner organisations might look - but it includes an awful lot of tools (see attached diagram). Possible to implement for our relatively tech-savvy team and perhaps not too daunting for a new generation used to a hundred-and-one apps on their mobile - but not so easy for a broader slice of society. 
>>>

[redrad...@gmail.com]

Hi Alastair

Hanging out in London would be nice but not really possible given that I am in Brisbane (Australia). But I can add my 5c worth as a professional software engineer.

1) Wordpress. 

Have you considered a content management system like Wordpress. I think almost 1/2 the web runs on this platform now. You can get basic services like authentication, authorisation, file management, etc. out of the box. Custom functionality can either be bought via configurable modules (cheap as chips and lots to choose from). Or by the development of a custom module. It uses PHP on the backend, MySql for the data store and you are free to add any javascript library on the front end if you want.

2) Mobile First. 

Lots of startups are looking at using apps rather than the web. Some companies just have a single web page, or even a Facebook page that simply points to Google Play and/or the Apple App store. The advantages of native apps are that you can do some really interesting things with GPS, Video, Photos, Offline Support and Syncing, and so on. Potentially even interface with the CNC Machine itself onsite if you are using a portable machine. Also not every country has a decent mobile network, such as Australia. Once you are outside the major metropolitan areas the mobile networks really suck. And I saw some stats recently that indicate that almost half of web site hits are from mobile devices. This is why Google tweaked it's search algorithm to rank mobile friendly sites higher. I'm sure there are lots of other places like this around the world. Typically people download apps when they are close to a decent Wifi connection. Then work offline till they come back into Wifi range. This is where native iOS and Android apps truly shine compared to web apps.

Well this may not be the direction you are heading in but I hope it gives you food for thought regarding your digital strategy going forward.

Regards

Rob

[Chau Huh]

I would second the wordpress platform.

I would also discourage you from locking people into using a single development tool. In my opinion, it seems counter to what the wikihouse ethos may be. While I do agree that a common file format can help, it can also greatly limit the tools that can be used and thus the people that can be involved.

Thanks.