Difference between revisions of "User:Inderpreet/OGV Proposal"
Inderpreet (talk | contribs) |
Inderpreet (talk | contribs) |
||
Line 9: | Line 9: | ||
===Background Information=== | ===Background Information=== | ||
− | I study in 4th year B.Tech (Computer Science and Engineering) at Guru Nanak Dev Engineering College, Ludhiana (India). I | + | I study in 4th year B.Tech (Computer Science and Engineering) at Guru Nanak Dev Engineering College, Ludhiana (India). I was introduced to this community about a year ago and have tried to help with whatever I could. I can speak in C++, PHP, Python, Javascript. |
==Project Information== | ==Project Information== | ||
===Brief Summary=== | ===Brief Summary=== | ||
− | 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 [https://www.meteor.com/ meteor]. Reason for this choice is 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. | + | 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 [https://www.meteor.com/ 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: -''' | '''Things that I will Improve on: -''' | ||
Line 20: | Line 20: | ||
* The way errors are given. (Many of the errors are not given at all) | * 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) | * The way Authentication is done (Will be handled by meteor now) | ||
− | |||
* Installation and Configuration | * Installation and Configuration | ||
* User Experience and User Interface | * User Experience and User Interface | ||
'''The features that I will add: -''' | '''The features that I will add: -''' | ||
− | + | * Dashboard (admin and non-admin) | |
− | * Dashboard | + | * Sharing & Embedding Feature |
− | + | * Image alternatives for 3D Models (Requested by Mediawiki) | |
− | * | + | * More Geometry Conversions. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | * Image alternatives for 3D Models (Requested by Mediawiki) | ||
==Detailed Project Description== | ==Detailed Project Description== | ||
Line 44: | Line 36: | ||
===Porting OGV to node.js=== | ===Porting OGV to node.js=== | ||
− | Online Geometry Viewer is currently written in plain PHP, and in discussions we all have agreed that we need to change that into something robust. Various suggestions were made and the Idea about using node.js survived. Then there was 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 | + | Online Geometry Viewer is currently written in plain PHP, and in discussions we all have agreed that we need to change that into something robust. Various suggestions were made and the Idea about using node.js survived. Then there was 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 alternates for each module in the sections below. | ||
===Improvements in OGV=== | ===Improvements in OGV=== | ||
Line 52: | Line 46: | ||
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. | 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 [http://amplifyjs.com/api/store/ amplify amplify.js]. Fortunately meteor has a package called [http://docs.meteor.com/#amplify amplify], that does exactly the same thing | + | 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 [http://amplifyjs.com/api/store/ amplify amplify.js]. Fortunately meteor has a package called [http://docs.meteor.com/#amplify amplify], that does exactly the same thing. |
====Errors==== | ====Errors==== | ||
− | 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. | + | 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. | ||
====Auth Module==== | ====Auth Module==== | ||
− | As also | + | 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 |
+ | * [http://docs.meteor.com/#allow connection.allow] for providing user roles. | ||
+ | * [http://docs.meteor.com/#accounts_api Accounts API] for handling accounts. | ||
+ | * [http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol Secure Remote Password Control] Support. | ||
+ | * [http://docs.meteor.com/#meteor_loginwithexternalservice 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=== | ||
+ | |||
+ | ====Dashboard==== | ||
+ | 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 Manager==== | ||
+ | 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. | ||
+ | *[https://atmosphere.meteor.com/package/Dropzonejs Dropzonejs] | ||
+ | *[https://github.com/CollectionFS/Meteor-CollectionFS CollectionFS] | ||
+ | |||
+ | ====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:- | ||
+ | *Like | ||
+ | *Share | ||
+ | ** 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. | ||
+ | |||
+ | ====Image Alternative==== | ||
+ | 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. | ||
+ | |||
+ | |||
+ | ==Milestones== | ||
+ | * 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) both | ||
+ | |||
+ | * '''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)''' | ||
+ | FINAL EVALUATION | ||
+ | |||
+ | ==My Prepration== | ||
+ | |||
+ | ==Why BRL-CAD?== | ||
+ | |||
+ | ==Why this project?== | ||
+ | |||
+ | ==Why Me?== | ||
+ | |||
+ | ==References== |
Revision as of 16:06, 18 March 2014
Contents
- 1 Online Geometry Viewer Project Proposal
Online Geometry Viewer Project Proposal
Personal Information
Name: Inderpreet Singh
Email Address: indrplus@gmail.com , singhs.ishwer@gmail.com
IRC Username: Ishwerdas
Background Information
I study in 4th year B.Tech (Computer Science and Engineering) at Guru Nanak Dev Engineering College, Ludhiana (India). I was introduced to this community about a year ago and have tried to help with whatever I could. I can speak in C++, PHP, Python, Javascript.
Project Information
Brief Summary
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
Online Geometry Viewer is currently written in plain PHP, and in discussions we all have agreed that we need to change that into something robust. Various suggestions were made and the Idea about using node.js survived. Then there was 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 alternates 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.
Errors
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.
Auth Module
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
Dashboard
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 Manager
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:-
- Like
- Share
- 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.
Image Alternative
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.
Milestones
- 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) both
- 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)
FINAL EVALUATION