Difference between revisions of "User:Inderpreet/OGV Proposal"
(→Porting OGV to node.js)
|Line 36:||Line 36:|
===Porting OGV to node.js===
===Porting OGV to node.js===
have to node.js. Then therea choice to be made among various kinds of frameworks, and then various frameworks in each kind. We decided to go with Full Stack frameworks like derby or meteor. I decided to choose meteor over others because it has a larger community i.e used and tested by more people as compared to others like derbyjs.
So My first task would be to replace each module of OGV to meteor. I have written about the
So My first task would be to replace each module of OGV to meteor. I have written about the for each module in the sections below.
===Improvements in OGV===
===Improvements in OGV===
Revision as of 20:30, 18 March 2014
- 1 Online Geometry Viewer Project Proposal
- 1.1 Personal Information
- 1.2 Project Information
- 1.3 Detailed Project Description
- 1.3.1 Porting OGV to node.js
- 1.3.2 Improvements in OGV
- 1.3.3 New Features to be added
- 1.4 Milestones
- 1.5 My Preparation
- 1.6 Why BRL-CAD?
- 1.7 Why this project?
- 1.8 Why Me?
- 1.9 References
Online Geometry Viewer Project Proposal
Name: Inderpreet Singh
Email Address: email@example.com , firstname.lastname@example.org
IRC Username: Ishwerdas
Online Geometry Viewer started as a GSoC 2013 project by Harmanpreet Singh. It's an online 3D geometry viewer that works on WebGL using three.js. For the server side purposes currently it uses vanilla PHP and jQuery, Bootstrap on the front-end. To give it a robust foundation, the community discussed about changing it's backend to something more powerful. I was part of that discussion and I gave my views. We all agreed on node.js to be a replacement for the current PHP based backend. We also agreed to use a Full Stack node.js framework such as derby or meteor. After looking at various frameworks I have decided to go for meteor. Reason for this choice is that meteor has a comparatively larger community which means more support, bugs removed quickly and more code to learn from. Then there's a list of things that need to be improved in current OGV and a list of features that need to be added.
Things that I will Improve on: -
- The way data is handled about models. (Currently GET method is used)
- The way errors are given. (Many of the errors are not given at all)
- The way Authentication is done (Will be handled by meteor now)
- Installation and Configuration
- User Experience and User Interface
The features that I will add: -
- Dashboard (admin and non-admin)
- Sharing & Embedding Feature
- Image alternatives for 3D Models (Requested by Mediawiki)
- More Geometry Conversions.
Detailed Project Description
As it's clear from the previous section the project is divided into three parts
- Porting OGV to nodejs (meteor)
- Improving the old and removing the bugs
- Adding New features
Porting OGV to node.js
We have made a choice to move to node.js. Then there's a choice to be made among various kinds of frameworks, and then various frameworks in each kind. We decided to go with Full Stack frameworks like derby or meteor. I decided to choose meteor over others because it has a larger community i.e used and tested by more people as compared to others like derbyjs.
So My first task would be to replace each module of OGV to meteor. I have written about the details for each module in the sections below.
Improvements in OGV
After we have a sound foundation with node.js, now we can concentrate on improving the existing OGV features.
Models Data Handling
Currently in upload_file.php, a list of names of obj files is sent to model_display.php using GET method. We can send a very limited amount of data through Get method. Larger models fail to get loaded because of this limit. It's just an array of file names so I will use HTML5 local storage to store this array locally on the client and fetch it again from there.
This will remove the bug and also add all the speed and benefits that come by storing data locally. Few older browsers do not support local storage so for them we can use a polyfill such as amplify amplify.js. Fortunately meteor has a package called amplify, that does exactly the same thing.
No matter how much we hate errors, they are very important to the user. They tell something is wrong and they contain information about solving itself. Can they be any nicer?
Currently at some places errors are not given to user at all and at other places errors are not that explanatory. For example there is no error given if the user account folder is deleted, neither a remedy is taken to create the user folder again. Just the models are not displayed in model_display.php without any error or any indication of something that has gone very wrong behind the walls.
Then there's a case with configuration errors, if say mged path is wrong then there's a small error in the sidebar of the model_display.php. Which is not clear and also gives no cue to user about how to solve that error.
For other errors like mysql credentials, I believe bootstrap's alert class needs to be used, so that it looks like an error. It's half of a UX problem and half of the functionality problem. For configuration errors, I have submitted a patch to the official github repository.
As also stated in To do list of OGV, current Auth system is not that secure and lacks robustness. Meteor has it's own robust authentication system. Secondly, current auth system does not have user roles but we need at-least two kinds of users, admin and non-admin. Admin user must be able to edit configuration files, add remove accounts etc, whereas non-admin can not do such tasks. Following features of meteor are going to help me with this
- connection.allow for providing user roles.
- Accounts API for handling accounts.
- Secure Remote Password Control Support.
- oAuth for logging in with various services such as facebook, twitter etc.
- The Accounts UI provided by meteor for user interface
And this all comes as one package with meteor.
Installation and Configuration
There's a scope of improvement in current OGV Installation, and also as we grow we need in place some standard Installation mechanism so that any user without any prior knowledge to any programming can Install it easily. I am inspired from Wordpress' 5 minute installation or Anchor CMS's 2 minute install to bring in OGV it's own easy install. I have worked on the configuration part and submitted a patch regarding it.
User Experience and User Interface
I am passionate about creating good interfaces. More than eye-candiness I care for the experience that user gets. To make things easy for the user. Then the second part of User Interface design is about prompting users to take actions. To make sign up buttons that no one can ignore but click. I will use bootstrap as underlying framework which I will edit to customize it specifically for OGV. I will be soon uploading pictures of mockups under this heading so stay tuned.
// more awesome content coming ...
New Features to be added
Currently we just have a upload button on the name of dashboard. I propose to add a full fledged dashboard where we can see all the models that we have previously uploaded. These dashboards will have options depending upon what kind of user you are. Admin user will have more options like Editing configuration files, adding/removing accounts etc. The rough list of what a dashboard will contain is as follows.
- A File manager, showing all your uploaded models.
- A button to upload your models.
- Option to edit your profile.
- View your profile (will contain feed of models you shared)
- Edit Configuration file / app settings. (Admin Only)
- Edit, Add or Remove Accounts (Admin Only)
File uploading is a little tricky part with meteor. Firstly, meteor does not have any ready-made built-in solution as such for file management (way it has for authentication). I have looked across some packages for meteor js that can be tried, tested and customized to feed our needs.
Sharing and Embedding
Social element in OGV is I guess the most exciting part of OGV. The ability to like other's models and share them among users. To share them on social network websites and have an embed code that can be used on any website. I would like to add following Social Features in OGV:-
- Share on Profile
- Share with unique URL
- Embed code
Likes and shares can be stored in database for each model. A unique URL is already being generated for each model, we just need to provide a way to share it. Embed code can be generated from this unique URL.
When I talked about Online Geometry Viewer on mediawiki mailing list they were kind enough to share their views and the features they would like for the extension. One of those features was to have an image alternative for each model. We can use earlier described File Manager packages to either make user upload an image or another approach can be, if once loaded on any client we can use .toDataURL() method of canvas to get image from canvas or a combination of both.
- Community Bonding Period
- Get more user requirements
- Start initial movement from PHP to meteor.
- Lots of healthy discussions about choices to be made.
- WEEK 1 (19th May)
Work on Authentication Module with Nodejs (meteor)
- WEEK 2 (26th May)
Port File Uploading to Nodejs (meteor)
- WEEK 3 (2nd June)
Write a File manager so that users can see old files and view them.
- WEEK 4 (9th June)
Start working on model display part with three.js aka work on using three.js along with meteor.
- WEEK 5 (16th June)
Continue working on display part, Handling models data, Saving data for later view.
- WEEK 6 (23rd June)
Make Viewer ready by making app call mged commands and geometry conversion commands on the server.
MID TERM EVALUATION
- WEEK 7 (30 June)
Make Dashboard for users and admins
- WEEK 8 (7th July)
Allow users to embed models in their websites.
- WEEK 9 (14th July)
Allow share and like on models
- WEEK 10 (21st July)
Revisit Dashboard to show user's Shares and Likes
- WEEK 11 (28th July)
Automate Installation and Configuration of the app.
- WEEK 12 (4th Aug)
Test the working , check bugs, Clean the code.
- WEEK 13 (11th Aug)
More testing, Check errors in Documentation.
- WEEK 14 (18 Aug)