You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At Offcourse, we love to do things differently. A different approach to education, a different approach to the development of the Offcourse platform. We have developed our platform in a way that everyone is able to understand it. In this way, you don't have to spend hours exploring the underlying code, but instead you can get started right away. In the upcoming paragraphs, we would like to introduce you to our approach, which is inspired by the methodology of atomic design. This will help to understand why we do things the way we do. So you will be able to contribute in the way you want to. Ready? Let's get started.
4
+
5
+
## A need for new ways of developing
6
+
7
+
Despite the relatively short history of web development, many things have changed in the way that websites are created. Initially, creating a website was a very straight-forward process, resulting in one static webpage. There was a huge lack of adaptability here, hence the step to responsive design was made. In practice however, it turned out to still be an insane amount of work to create smooth multi-device web experiences using responsive design. The next step to front-end frameworks such as Bootstrap seemed logical, yet its limitations made the approach perfect for MVP's and speedy development, yet not for in-depth web development.
8
+
9
+
We have seen that current widespread practices fall short and a need for new approaches becomes clear. In an ideal world, a systematic way of thinking would exist that allows for web development that is extremely adaptable, consistent, easy to share and test, speedy to use and lasts for years. If only someone would have come up with such a system..
10
+
11
+
## The rational behind atomic design
12
+
13
+
Actually, a guy named Brad Frost has, inspired by the natural world, developed an interface design system called **atomic design**. This methodology, composed of five distinct stages working together, can be used to create interface design systems in a more deliberate and hierarchical way.
14
+
15
+
The five stages of atomic design are: 1) atoms 2) molecules 3) organisms 4) templates and 5) pages. The foundations of Offcourse are based on this methodology, hence we think it is important for you to get introduced to the matter. In the next section, we will quickly take you through the basics of these stages.
16
+
17
+
First of all, **atoms** serve as the smallest building blocks possible that comprise all of the user interfaces. In this way, atoms are the foundation of the interfaces. The atoms include basic HTML elements such as *buttons*, *inputs*, *form labels* and others that can’t be broken down any further without ceasing to be functional. In simple words, atoms are the smallest LEGO building blocks possible to start building with.
18
+
19
+
Several atoms can be grouped into **molecules** to function as simple user interface (UI) elements in interfaces. In this way, atoms such as a *search input*, *form label* and *button* can be used to create a search form molecule. By combining atoms into molecules, suddenly the atoms have purpose. If we use the comparison of atoms as the LEGO building blocks, a molecule could be a wall, which is build up from these separate building blocks.
20
+
21
+
Following, molecules and/or atoms can be combined into **organisms**, which are relatively complex UI components. Organisms form distinct sections of an interface. In the case of Offcourse, an organism is for example the card feature on the platform. In the LEGO case, several molecules (walls, doors and a roof) could be combined to create a complex component, namely a LEGO house.
22
+
23
+
**Templates** are page-level objects that are used to place components into a layout. Templates structure the necessary page components and shows how they function together, providing a context for the molecules and organisms. So in a way, templates are used to structure the different bits and pieces and position them in the blank canvas of the webpage. It is important to realize that templates focus on the page’s underlying content structure rather than the page’s final content.
24
+
25
+
Finally, with the introduction of pages, representative content is introduced. **Pages** are instances of templates that demonstrates the final interface as the users will see it, using real content when displaying it. Pages can be used to test the effectiveness of the design system, but are also a useful tool to articulate variations in templates. This functionality is vital in the development of reliant and robust design systems.
26
+
27
+
```image
28
+
plain: true
29
+
src: "assets/atomic-design.png"
30
+
description: "_Above, Brad Frost applied his atomic design methodology to the native mobile app Instagram._"
31
+
```
32
+
33
+
Now that you have a basic understanding of atomic design, you will be able to understand our documentation for development a lot better. All the features of the Offcourse platform are built according to this principle of atomic design. So when you get involved, think in bits and pieces, building blocks. Get inspired by the atoms, molecules and organisms that we have created so far.
34
+
35
+
*The content of this page is based on our interpretation of the online version of Brad Frost's Atomic Design. The images and all other rights related to his content belong to him. Interested in reading more about the atomic design methodology? Have a look at Brad Frost's atomic design website*[*here*](http://atomicdesign.bradfrost.com/table-of-contents/).
Curious to know what features you can help us develop?
2
2
3
-
Curious to know what features you can help us develop?
3
+
You will see on our roadmap that there are a lot of opportunities to expand the functionalities of the platform, both the functionality of the course cards as well as navigation on the platform for example.
4
+
We continuously update our roadmap with new features.
4
5
5
-
You will see on our roadmap that there are a lot of opportunities to expand the functionalities of the platform, both the functionality of the course cards as well as navigation on the platform for example.
6
-
We continuously update our product roadmap with new features.
7
-
8
-
We are also open to discuss features you would like to work on that are not on our roadmap. You can get in touch via [email](mailto:contact@offcourse.io) to discuss the possibilities.
6
+
We are also open to discuss features you would like to work on that are not on our roadmap. You can get in touch via [email](mailto:contact@offcourse.io) to discuss the possibilities.
Copy file name to clipboardExpand all lines: packages/documentation/public/how-to-contribute.md
+22-24Lines changed: 22 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,17 +1,15 @@
1
-
# Contributing Guidelines
2
-
3
1
👍🎉 First off, thanks for taking the time to contribute! 🎉👍
4
2
5
3
The following is a set of guidelines for contributing to the further development of the Offcourse platform, which is hosted on the [Offcourse-Next GitHub repo](https://github.com/OffCourse/offcourse-next). All fundamentals for design, coding and the work ethos of the Offcourse community can be found seperately at ...
6
4
7
5
## Table Of Contents
8
6
9
-
* Code of Conduct
10
-
* What should I know before I get started?
11
-
* How Can I Contribute?
12
-
* Reporting Bugs
13
-
* Suggesting Enhancements
14
-
* Contributing changes (Bug fixes, Code Contribution and Pull Requests)
7
+
- Code of Conduct
8
+
- What should I know before I get started?
9
+
- How Can I Contribute?
10
+
- Reporting Bugs
11
+
- Suggesting Enhancements
12
+
- Contributing changes (Bug fixes, Code Contribution and Pull Requests)
15
13
16
14
## Code of Conduct
17
15
@@ -27,9 +25,9 @@ JavaScript, on the other hand, has moved in the opposite direction. There is an
27
25
28
26
If you are interested in contributing to our open source project, you can make a contribution by one of the following:
29
27
30
-
* Reporting Bugs
31
-
* Suggesting Enhancements
32
-
* Contributing changes (Bug fixes, Code Contributions and Pull Requests)
28
+
- Reporting Bugs
29
+
- Suggesting Enhancements
30
+
- Contributing changes (Bug fixes, Code Contributions and Pull Requests)
33
31
34
32
## Reporting Bugs
35
33
@@ -39,35 +37,35 @@ The Offcourse platform is under continuous development. Bugs are a natural part
39
37
40
38
Make sure your report gets the attention it deserves: bug reports with missing information may be ignored or punted back to you, delaying a fix. The below constitutes a bare minimum; more info is almost always better:
41
39
42
-
***A detailed description of the bug**. Describe how the bug occurred, what action you took when it happened. Also, include print screens.
43
-
***What version of the core programming language interpreter/compiler you are using.**
44
-
***What operating system you are on.** Windows? (Vista? 7? 32-bit? 64-bit?) Mac OS X? (10.7.4? 10.9.0?) Linux? (Which distro? Which version of that distro? 32 or 64 bits?) Again, more detail is better.
45
-
***Which version or versions of the software you are using.** Ideally, you followed the advice above and have ruled out (or verified that the problem exists in) a few different versions.
40
+
-**A detailed description of the bug**. Describe how the bug occurred, what action you took when it happened. Also, include print screens.
41
+
-**What version of the core programming language interpreter/compiler you are using.**
42
+
-**What operating system you are on.** Windows? (Vista? 7? 32-bit? 64-bit?) Mac OS X? (10.7.4? 10.9.0?) Linux? (Which distro? Which version of that distro? 32 or 64 bits?) Again, more detail is better.
43
+
-**Which version or versions of the software you are using.** Ideally, you followed the advice above and have ruled out (or verified that the problem exists in) a few different versions.
46
44
47
45
## Suggesting enhancements
48
46
49
47
Feature requests and Design Change Requests (DCRs) are an important part of the lifecycle of any software project. Please log these as Issues in the GitHub repository. Again, please provide us with the necessary information so we, and other community members, understand the value of the request. This includes:
50
48
51
-
* Detailed scenarios enabled by the feature or DCR.
52
-
* Information about your use case or additional value you / your business will see from the feature.
53
-
* Any design tips or estimation ideas you may have considered already.
54
-
* Make note of whether you are opening an issue you would like the Offcourse team or another community member to work on *or* if you are looking to design & develop the feature yourself.
55
-
* Any potential caveats or concerns you may have already thought about.
56
-
* A miniature test plan or list of test scenarios is always helpful.
49
+
- Detailed scenarios enabled by the feature or DCR.
50
+
- Information about your use case or additional value you / your business will see from the feature.
51
+
- Any design tips or estimation ideas you may have considered already.
52
+
- Make note of whether you are opening an issue you would like the Offcourse team or another community member to work on *or* if you are looking to design & develop the feature yourself.
53
+
- Any potential caveats or concerns you may have already thought about.
54
+
- A miniature test plan or list of test scenarios is always helpful.
57
55
58
56
## Contributing changes
59
57
60
58
This constitutes bug fixing as well as the contribution to a new feature from our roadmap and code contribution in general. You will find our bug database and roadmap soon to see what contributions can be made here. The following are guidelines for working on such changes.
61
59
62
-
Before you start working on a feature or substantial code contribution that is not in our bug database or on our roadmap, please discuss it with the team and ensure it is an appropriate addition to the core product. You can do this by sending an email to contact@offcourse.io.
60
+
Before you start working on a feature or substantial code contribution that is not in our bug database or on our roadmap, please discuss it with the team and ensure it is an appropriate addition to the core product. You can do this by sending an email to [contact@offcourse.io](contact@offcourse.io)
63
61
64
62
## **Version control branching**
65
63
66
-
* Always **make a new branch** for your work, no matter how small. This makes it easy for others to take just that one set of changes from your repository, in case you have multiple unrelated changes floating around.
64
+
- Always **make a new branch** for your work, no matter how small. This makes it easy for others to take just that one set of changes from your repository, in case you have multiple unrelated changes floating around.
67
65
68
66
> A corollary: don’t submit unrelated changes in the same branch/pull request! The maintainer shouldn’t have to reject your awesome bugfix because the feature you put in with it needs more review.
69
67
70
-
***Base your new branch off of the appropriate branch** on the main repository:
68
+
-**Base your new branch off of the appropriate branch** on the main repository:
71
69
72
70
Bug fixes should be based on the branch named after the oldest supported release line the bug affects.
0 commit comments