Skip to content

rangoc/MordOS

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 

History

64 Commits
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Netlify Status

Demo

MordOS - One OS to rule them all

Screenshots

Desktop:

Desktop-Authentication1.png TextFile.png File-Directory-Desktop.png Gallery.png Browser.png

Mobile

Mobile.png

How to run

git clone the project locally
yarn install to install all the dependencies
yarn start to run the project in your browser

Project overview

Functional requirements:

The client requested for a graphical user interface for a web based operating system. Considering that this is an MVP, functionality is supposed to be far from an OS but it does need to look and feel like an OS, to be appealing and fun to explore. Borgoth, being the imaginary flaming venture demon, should be this operating system's brand.
Client also requested functionalities that they thought might bring a lot of value, such as:

  • Mord OS should support creating and managing plain text files and include a directory mechanic in order to sort the files as one wishes.
  • There should be a simple authentication feature so not everyone can access the OS. A simple email and password flow will do for now. ( email: borgoth@mordos.com / pass: 12bindthem)

Other functionalities that are not as crucial but could really help enrich the OS:

  • To keep up with all the news and banter going on, the OS could include a dedicated RSS reader app. (data source: https://jsonplaceholder.typicode.com/comments)
  • Having a Camera app seems like a must for any OS today.
  • It would be good if the OS had a Gallery app to view images from different sources without having to switch. (data source: https://jsonplaceholder.typicode.com/photos , but can include others)
  • The OS could also have a dedicated web browser. Can be simple at first.

Visual requirements

Creative freedom given as long as the following visual requirements are respected:

  • The OS should look familiar to other systems so it doesn’t create confusion.
  • No visual UI libraries should be used.
  • Keep it sane :exploding_head:

Deadline: 7 days

Implementation & Thought process

Visuals

Assets & color palette

Due to the client's requirement that Borgoth, an imaginary flaming venture demon, be the operating system's brand, I had to first find the appropriate assets to use ( drawings, photos ) e.g. logo, and it was critical that this asset be creative, fiery, and serious, as that was the style I was aiming for as an end-goal. I had already decided that the entire OS would have a Ubuntu-ish look, and this image worked perfectly (it's worth noting that Photoshop had to be used in order to make a vector-based logo that would scale well quality-wise on different screen sizes, because the original source was a png with a solid background, so I had to remove the background and convert whole shape to svg).
I chose the colors orange/yellow/red and purple since they are the most representative of Borgoth ( a venturing flaming demon ) and Ubuntu.

UI
Background

Once I had logo and palette in place, I decided on a stellar system as a background, which perfectly complemented the already familiar look of Ubuntu ( due to the purple color ) and Borgoth's, who is described as a venturing demon, and what better place to venture out than a universe and it's stellar system πŸ•³οΈ?

App bar

The App bar was designed to look like the already-familiar Ubuntu style, with apps arranged vertically along the left edge of the screen. In order to make the entire user experience more user friendly, a hover effect with a tooltip should also be provided.

App window

The App window should have a header with the app's icon and a 'X' (close window) icon. Because I, like Borgoth, am a great fan of dark themes,I decided that the section where the App's specific content will be rendered will have a dark background. 😁

That's pretty much it; everything else is basically little designer touches that are somewhat subjective to taste, such as fonts, input field styles and buttons, all of which can be found in sass files and code without me having to go into detail about them.

Functions

I'll try to keep this one short by simply giving a brief summary of the functionalities and how I implemented them; of course, the code is available for a more in-depth look. 😁

Project anatomy:
β”œβ”€β”€ public
β”‚   β”œβ”€β”€ favicon.ico
β”‚   β”œβ”€β”€ index.html
β”‚   β”œβ”€β”€ manifest.json
β”‚   └── robots.txt
β”œβ”€β”€ README.md
β”œβ”€β”€ src
β”‚   β”œβ”€β”€ App.js
β”‚   β”œβ”€β”€ app.scss
β”‚   β”œβ”€β”€ assets
β”‚   β”‚   β”œβ”€β”€ cancel.svg
β”‚   β”‚   β”œβ”€β”€ fileDirectory.svg
β”‚   β”‚   β”œβ”€β”€ file.svg
β”‚   β”‚   β”œβ”€β”€ gallery.svg
β”‚   β”‚   β”œβ”€β”€ logo.svg
β”‚   β”‚   β”œβ”€β”€ rssFeed.svg
β”‚   β”‚   β”œβ”€β”€ textFile.svg
β”‚   β”‚   β”œβ”€β”€ ui-background.svg
β”‚   β”‚   β”œβ”€β”€ webBrowser.svg
β”‚   β”‚   └── webcam.svg
β”‚   β”œβ”€β”€ components
β”‚   β”‚   β”œβ”€β”€ appbar
β”‚   β”‚   β”‚   β”œβ”€β”€ AppBar
β”‚   β”‚   β”‚   β”‚   β”œβ”€β”€ AppBar.js
β”‚   β”‚   β”‚   β”‚   └── appbar.scss
β”‚   β”‚   β”‚   └── Icon
β”‚   β”‚   β”‚       β”œβ”€β”€ Icon.js
β”‚   β”‚   β”‚       └── icon.scss
β”‚   β”‚   β”œβ”€β”€ auth
β”‚   β”‚   β”‚   β”œβ”€β”€ Authentication.js
β”‚   β”‚   β”‚   └── authentication.scss
β”‚   β”‚   β”œβ”€β”€ fileDirectory
β”‚   β”‚   β”‚   β”œβ”€β”€ Arrow
β”‚   β”‚   β”‚   β”‚   └── Arrow.js
β”‚   β”‚   β”‚   β”œβ”€β”€ File
β”‚   β”‚   β”‚   β”‚   β”œβ”€β”€ File.js
β”‚   β”‚   β”‚   β”‚   └── file.scss
β”‚   β”‚   β”‚   └── FileDirectory
β”‚   β”‚   β”‚       β”œβ”€β”€ FileDirectory.js
β”‚   β”‚   β”‚       └── fileDirectory.scss
β”‚   β”‚   β”œβ”€β”€ gallery
β”‚   β”‚   β”‚   β”œβ”€β”€ Gallery
β”‚   β”‚   β”‚   β”‚   β”œβ”€β”€ Gallery.js
β”‚   β”‚   β”‚   β”‚   └── gallery.scss
β”‚   β”‚   β”‚   └── Photo
β”‚   β”‚   β”‚       β”œβ”€β”€ Photo.js
β”‚   β”‚   β”‚       └── photo.scss
β”‚   β”‚   β”œβ”€β”€ rssFeed
β”‚   β”‚   β”‚   β”œβ”€β”€ Comment
β”‚   β”‚   β”‚   β”‚   β”œβ”€β”€ Comment.js
β”‚   β”‚   β”‚   β”‚   └── comment.scss
β”‚   β”‚   β”‚   └── RssFeed
β”‚   β”‚   β”‚       β”œβ”€β”€ RssFeed.js
β”‚   β”‚   β”‚       └── rssFeed.scss
β”‚   β”‚   β”œβ”€β”€ textFile
β”‚   β”‚   β”‚   β”œβ”€β”€ CreateModal
β”‚   β”‚   β”‚   β”‚   β”œβ”€β”€ CreateModal.js
β”‚   β”‚   β”‚   β”‚   └── createModal.scss
β”‚   β”‚   β”‚   β”œβ”€β”€ CreateTextFile
β”‚   β”‚   β”‚   β”‚   β”œβ”€β”€ CreateTextFile.js
β”‚   β”‚   β”‚   β”‚   └── createTextFile.scss
β”‚   β”‚   β”‚   β”œβ”€β”€ EditTextFile
β”‚   β”‚   β”‚   β”‚   └── EditTextFile.js
β”‚   β”‚   β”‚   └── HintOverlay
β”‚   β”‚   β”‚       β”œβ”€β”€ HintOverlay.js
β”‚   β”‚   β”‚       └── hintOverlay.scss
β”‚   β”‚   β”œβ”€β”€ ui
β”‚   β”‚   β”‚   β”œβ”€β”€ Logo
β”‚   β”‚   β”‚   β”‚   β”œβ”€β”€ Logo.js
β”‚   β”‚   β”‚   β”‚   └── logo.scss
β”‚   β”‚   β”‚   └── UserInterface
β”‚   β”‚   β”‚       β”œβ”€β”€ UserInterface.js
β”‚   β”‚   β”‚       └── userInterface.scss
β”‚   β”‚   β”œβ”€β”€ webBrowser
β”‚   β”‚   β”‚   β”œβ”€β”€ WebBrowser.js
β”‚   β”‚   β”‚   └── webBrowser.scss
β”‚   β”‚   β”œβ”€β”€ webcam
β”‚   β”‚   β”‚   β”œβ”€β”€ Webcam.js
β”‚   β”‚   β”‚   └── webcam.scss
β”‚   β”‚   β”œβ”€β”€ Window.js
β”‚   β”‚   └── window.scss
β”‚   β”œβ”€β”€ constants
β”‚   β”‚   β”œβ”€β”€ appType.js
β”‚   β”‚   β”œβ”€β”€ sortType.js
β”‚   β”‚   └── validCredentials.js
β”‚   β”œβ”€β”€ context
β”‚   β”‚   β”œβ”€β”€ AuthProvider.js
β”‚   β”‚   β”œβ”€β”€ TextFileProvider.js
β”‚   β”‚   └── WindowProvider.js
β”‚   β”œβ”€β”€ hooks
β”‚   β”‚   └── useFetch.js
β”‚   β”œβ”€β”€ includeMedia.scss
β”‚   β”œβ”€β”€ index.js
β”‚   β”œβ”€β”€ index.scss
β”‚   └── utils
β”‚       └── sortFiles.js
└── yarn.lock
Context
  • AuthProvider - Authentication context which wraps whole application and exposes auth state and functions.

  • WindowProvider - Window context which wraps whole UserInterface component and exposes window state and functions.

  • TextFileProvider - Text File context which wraps whole UserInterface component and exposes state and functions related to text files and it's management.

Components
  • App - renders Authentication / UserInterface based on the isAuthenticated.

  • Authentication - responsible for holding the auth form and simple auth validation.

  • UserInterface - responsible for rendering individual Apps in windowArea ( space on screen dedicated solely to the Apps window and it's content) based on the active status coming from WindowProvider.

  • AppBar - responsible for triggering each Application's active status.

  • TextFile - responsible for text files Create / Update part of CRUD set of functionalities.

  • FileDirectory - responsible for text files Read / Delete part of CRUD set of functionalities.

  • Gallery - utilizes useFetch custom hook for data fetching.

  • RssFeed - utilizes useFetch custom hook for data fetching.

  • WebCam - provides integration with your own webcam feed coming from your personal computer/phone.

  • WebBrowser - simulates a real web browser by allowing a user to see the content of requested url embedded inside of an iframe.

  • Window - reusable, serves as a wrapper around each app and provides it with themed styling while allowing customization.

Custom hooks
  • useFetch - receives an url as an argument, generic custom hook that can be used to retrieve data.

Additional improvements / features suggestions:

  • Drag & Move - window feature that allows user to drag and move App's window across the screen. It could be built by trying to register the mouse events such as onMouseDown,onMouseUp & onMouseMove of the ref element while keeping track of the current's mouse position coordinates on the screen. Certain limitations on the boundaries of the area that's allowed to be used, should also be set.

  • "Priority" of windows - a feature that allows for windows to take priority based on the selected status. This feature could be implemented by dynamically assigning z-index to a currently selected window.

  • File upload - a feature that let's user upload his own text file inside of FileDirectory component, could be accomplished by combining input field for file upload and Fetch Api / Axios library.

  • Camera upload - a feature that let's a user take & save a picture taken with his webcam to Gallery component.

  • More than one instance of same app running - currently, the OS is designed in a way which allows for a user to only activate one instance of the same App type. One of the potential improvements would be to allow for a user to edit more than one text file concurrently. But hey, this isn't a bug, it's a feature πŸ™ƒ

... and many more, but these would be some of the first ones that could be done in the next iteration of upgrades, when it comes to this specific MVP.

Things that I would do differently:

  • Saving user's credentials & session inside of localStorage - 🀐 This is a massive no-no. But this was done solely for the sake of convenience, to avoid accidental refreshes when exploring MordOS, and because Borgoth would be furious if he had to authenticate a user who had been authenticated just seconds before 😁. So this was only done to calm Borgoth's rage; otherwise, if we were talking about a production scenario with a real backend, this would surely be done through JWT.

  • Using my own media queries - If we're talking about optimizations, this would be one of the areas where we could make improvements. The one file includeMedia.scss is responsible for a large amount of the project's sass percentage, but on the other hand makes media queries much easier and intuitive. However, for such tiny projects as this one, it may be an overkill, especially if optimization is an issue. So, if it became necessary, I would definitely utilize my own media queries.

  • Using an iframe as a solution for a dedicated web browser - iframes aren't really generous and they have their drawbacks, such as :

    • Trying to embedded some sites, e.g. google, will result with google.com refused to connnect due to the google's own configuration which refuses to display it in a frame because it set X-Frame-Options to sameorigin.

Most painful point of the project:

The architecture was undoubtedly one of the aspects of the project that I had the most trouble with, and that required the most modifications and thought. At first, I was obsessed with creating the ideal, most reusable, most generic architecture in order to adhere to the DRY principle, but halfway through the project, I began to doubt my model owing to the unique requirements of each subsequent task. As a result of that unique requirement, the model had to be revised and slightly redesigned specifically to meet that requirement, casting doubt on the DRY principle and my architecture. And who knows, if this MVP continues to evolve, perhaps even more extensive remodeling will be required, thus coming up with the correct architecture design remains one of the most difficult challenges for me to solve. 😁

Final Words

This project was a blast to work on. The client's creative flexibility was liberating, and it allowed me to demonstrate my ability to 'wear a different hat' depending on different tasks, ranging from graphics/ux design to web development, which is my passion. Borgoth was an ultra fun character to create story around, and even though the idea of implementing the functionalities of an operating system inside of a browser sounds really wild, I learned a lot with this project. Will definitely work with this client again, if the opportunity arises.

Thanks for a read! Cheers 🍺
Looney Tunes

About

Operating system inside of a browser ( MVP )

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published