OSArch website design

edited November 2020 in General

@duncan mentioned how it would be a good idea to actually have some sexy sites showcasing what we're up to. I thought I'd see if any further thoughts were given to:

  • What should be included on the site
  • If there was a layout sketched out
  • Who might provide the content?

Personally, I would keep the OSArch main site to be basically a static poster site, and leave all the text-heavy content (guides / tutorials / other resources) to the wiki, where everybody can contribute.



  • We want to develop a website for DfMALab (https://github.com/dfmalab) so I think we can work all together to develop the website for both BlenderBIM and DfMALab
    I checked a lot of websites and I think the best one is: https://github.com/fabfoundation/fabfoundation

  • edited June 2020

    I'm mostly think about a landing site which is just a showcase linking to everything else. So it could be hand built or whatever, just as long as it's eye candy at the first layer, maybe workflows in the second layer ... and then links to all the detailed goodies we have collectively. Maybe we could start with a gallery with tags so all images get at least #projectname #software #author
    Can we do that on the wiki? I haven't found how to upload images to that wiki yet.

  • @duncan I think regards to the wiki, I think Dion's choice is good and it supports images and videos, indeed it's Wikipedia, however, needs some experience to work with
    The second choice could be https://github.com/squidfunk/mkdocs-material which is markdown-based
    About website, it depends and I think Dion thinks about simplicity so even a landing page, or some pages can handle everything I think

    But I think about a lab that always has a lot of experimental projects, so should be something like the website I shared

  • @duncan upload rights need to be granted on the Wiki. I have just granted you access! Have fun!

  • I've had some more thoughts about how the website could look. A tab each for Architecture / Engineering / Construction / Operations. I would include Landscape in the architecture tab. All deep analysis would belong on the engineering tab. Superficial analysis such as shadows and basic lighting info could be on the architecture tab. Each tab is a workflow with branches/links to more complex workflows and alternative tools. How does that sound? We could implement it first on the wiki and later on a more graphics oriented CMS.
    How does that sound? We need to work on documenting workflows anyway.

  • I really like that idea! Being "domain" focused rather than tool focused sounds like the right approach. Also good to start on the wiki.

  • Sounds great to me also

  • I foun this in the FreeCAD forum: The switch2osm.org web site from Open Street Map. This web help people to move from a less-free environment of maps like GoogleMaps to the Open Street map. Maybe this kind of focus it would be interesting to include in the web.

  • So I just noticed there were a couple minor tracking URLs on the forum: usage of Google Font's CDN, and the Vanilla forum's analytics tracker. I've disabled both of these as a matter of principle and respect to the users of OSArch. If you spot any more, let me know :)

    The only analytics being tracked on OSArch domains are the web server (nginx) access logs, which store the standard variables required for HTTP requests to work. For those interested, I've published an aggregation of them online:


    Enjoy :)

  • In the spirit of being "domain focused" what is your thoughts on the naming structure of the website's subdomains and subpages with regards to each topic (archictecture, engineering or constructions)?

    A proposal (albeit a bit controversial) where each subdomain represents a specific topic could be re-structuring "osarch.org" into a parent domain "osaec.org" (landing page) (representing the parent domain Open Source Architecture, Engineering and Construction) with subdomains "eng.osaec.org", "arch.osaec.org" and "cons.osaec.org" representing each topic?

    I guess some of the counter arguments would be that "osarch" is easier to pronounce than "osaec" and the name "osarch" is already somewhat established :) But I can't really shake the feeling that a re-structuring like what I proposed just seems a bit more natural (if we wanted to include the major domains in AEC)?

    Maybe I am way off and its just the structural engineer in me not yet having come to terms with seeing engineering ending up as a subdomain to an architecture parent domain:)

    Any thoughts?

  • @krande too much engineering thought in your proposal :D :D
    I do not think that dividing the domain addresses will be good; I prefer a single page of threads, otherwise we will end up hoping from one to the other and we will lose communication between the members. Other than that, your proposal for domains is coherent with the proposal of @duncan with the tabs for the presentation of relevant projects/etc.

  • Perhaps we could have optional labels in the threads to be chosen by the author, which could help filter them if someone is interested for example only in a specific domain.

  • edited August 2020

    @Jesusbill you are probably right:)

    I completely agree its best having all topics discussed in the same community thread. I guess my suggestion would be more relevant if we wanted to create a set of static web pages (subdomains) to showcase various cool applications of open source AEC software (a subdomain for each respective topic) and write some blog posts covering each example in more detail. And I guess if we were to follow the aforementioned suggested domain structure, it would make sense to let the community be "as-is" in one place as "community.osaec.org" (and the same for the wiki "wiki.osaec.org").

    But in the end, it's the content that really matters. So I will be perfectly happy with whatever domain names and structure we end up with :)

  • edited August 2020

    I regard all of what we're doing now as community building alpha. When we have god landing pages and more structure we're at our first beta. By then we might know enough about what we're doing to get smart with domains - for now I think it's good to stay flexible and not do things that are hard to change along the way. I also have reservations about the name, structure and so on ... but let's make a good 'product' with the resources and setup we have before we get to deep into details.

  • Because anything is better than the previous "Under construction" text, here's a slightly sexier landing page: https://osarch.org/ - the globe graphic was a spur of the moment type of design (done in Inkscape), but if we like it, we can keep it :)

    @duncan and I have started migrating the free software directory links to internal wiki pages, like this: https://wiki.osarch.org/index.php?title=BlenderBIM_Add-on - still uncertain how it should fully be structured, but I hope to cover the following questions:

    1. Show the user an icon and a screenshot, graphics are nice.
    2. There should be some description features, tailored to AEC
    3. Link to website. Link to source. Link to community outlets.
    4. Getting started for beginners.
    5. How to contribute to the project - do they have a GSoC program? Do they have a junior jobs list? Do they have a community fund or dev sponsor links? Etc.

    ... slowly getting there!

  • edited August 2020

    @Moult I can't see a changed index page. I also want to say that I think we should be careful about duplicating efforts. If the software we mention already has a good website I won't be spending time on our wiki doing anything but linking to their website. As you say a short description of how it is relevant to AEC0 may be necessary sometimes. I've just been trying to make a template for https://wiki.osarch.org/wiki/Template:Infobox_software without any luck. Is there anything you know of in the settings stopping this?
    (If your globe graphic doesn't include New Zealand I'll go on strike)

  • @Moult I've tried a few things on the wiki that haven't worked. I can't make template or categories work. Is there a setting somewhere that needs to be switched? I'd really like to begin using those two functions.

  • I like wiki, however, I think this one is better: https://squidfunk.github.io/mkdocs-material

  • @duncan Just tested creating a template: https://wiki.osarch.org/index.php?title=Template:HelloWorld - seems to work fine. You're an admin, so you should be able to do everything I can do.

  • How do we differentiate between the many incomplete or narrow niche projects and the projects that deserve to be featured as great examples people can easily get started using?
    Some ideas:

    • we could write a "feature" article every now and then and share it on social media about a great package and what it can do
    • we could indicate for every package on the list what level of maturity they have.
    • we could use some graphic signals and place one package at the top of each list as the featured package for that category (making more categories is also fine as they're easy to navigate from the top of the page
    • other suggestions ... ?
      I've been generally trying to add more structure to the website - is it working? Are things intuitive to find? Are the most important things easy to find?
  • Ok now I'm lost as well. If I understand correctly the idea is having two sites?:
    1. Landing presentation website, mostly eye candy, graphical, to convince people that they just found the doorway to a new world which will turn their life upside down (https://osarch.org/)
    -is there a wip version @duncan is working on I can see? or do I understand it completely wrong? My general idea of what it should look like is for example the new https://graphisoft.com/solutions/products/archicad website. "Work smarter, not depending on closed corporations that can milk you anytime they feel like it."
    2. Wiki with all the content, where people will see all the madness and brilliance coming together and hopefully make something useful out of it. (https://wiki.osarch.org/index.php?title=Main_Page)
    Here I find the new landing page is too technical and still lacks a clear structure. My suggestion would be:
    1. Overview of open AEC resources
    2. Open source architecture workflows
    3. Technical standards and solutions
    4. How to contribute the OSArch community

    @duncan articles for social media are great, however I'd prefer stories of concrete results achieved with the package, I feel like the pictures @Moult is posting are catching way more attention than the packages themselves, since they are not so polished.
    One more point should be our road map, the development is currently rolling incredibly fast, it is important to show that the feature we don't have right now might be ready in a month.

  • edited August 2020

    @JanF good thoughts thanks. Yeah 2 sites like you said a lobby and a library - or however we want to describe it. ArchiCADs site is nice, sure something like that. I'm not convinced we're ready for it and that's why I've stopped talking about it to focus on the wiki. The four points you've there are maybe a way forward. At he moment I've been organising things from the front page (which was one long mess) into categories and pages with banners. Once this is finished it should be easier to see what we have and do the top level organisation. At the moment I just don't think we have good enough/enough good content on the wiki. The idea behind featuring software and writing articles is to focus on better content. It could help us focus on what we know is working well.
    Jump in and make some changes to the wiki if you think they're obvious.

  • @duncan said:
    @JanF good thoughts thanks. Yeah 2 sites like you said a lobby and a library - or however we want to describe it. ArchiCADs site is nice, sure something like that.

    I suggest FreeCAD's landing page; it follows this same concept; it has a general overview with pretty pictures, but basically any link that you click will take you to the wiki, which is much uglier unfortunately.

    The idea behind featuring software and writing articles is to focus on better content. It could help us focus on what we know is working well.

    Images. Images and diagrams are what attracts users to the software. So, my advice is to provide images that show effective use of the software, and minimize the use of text. Simple and short sentences are more effective than long explanations. Also avoid the urge of posting too many external links to other websites or tutorials; it's quite tempting to just fill a page with links in an effort to provide a lot of information. However, these external links tend to rot away or become obsolete as the amount of information in the wiki grows. A single point of entry should be preferable; for example, if you need to talk about IfcOpenShell, I would create a wiki page for this software, that all others pages would link to, instead of each page linking to IfcOpenShell.org by themselves.

  • @vocx everything you say is what I'm slowly doing with the wiki. But I can't do i alone. There is the added complication that some packages have so little documentation that the wiki may be their primary documentation. I'm trying to deal with this by using categories.
    @ReD_CoDE where are you thinking those icons could be useful? Do you have some examples for where they could be used?

  • Hi @Moult & @theoryshaw is this your staircase? https://forums.buildingsmart.org/t/presenting-blender-as-a-new-ifc-authoring-tool/1791/65
    I'd like to add some of that to the OSArch wiki as examples of documentation. But I'd like a short description of what's in them. Especially in general terms how much is model based and how much is added outside the modelling software (in Inkscape?)

  • @duncan it's a steel staircase with wooden cantilever treads I did for a co-worker to build at his house. It was all model based, nothing was added in Inkscape.

  • @Moult I'd love to include them in the wiki. Are the project files available and copy-left?

  • I'm thinking our software list is starting to break down - we really need tags instead of separate lists. Make sense? It's easy enough to do, just requires links to category lists for each agreed "tag".

  • I think one of the tags should be actively used by a list member.

Sign In or Register to comment.