janetzki / mechanism-browser Goto Github PK

(Parts of the original issue were moved to #78)

Just encountered some cool mechanisms that are inherently variable in their transmission ratio. Pretty sexy, but maybe a feature we should include. add a checkbox "transmission range" and then let the user specify the min and max transmission

this makes it evident for somebody else that this still needs to be calculated, can be a simple checkbox
so in this case I may not know the exact transmission ratio (would have to be calculated) but the mechanism is interesting as such. Anyone else should be able to come in and modify that

They should probably be scaled to >100 pixels width and then cropped. But this should be done automatically to reduce user effort

User Story: As a user of the mechanism browser, I want to select/deselect rotation axes by clicking on the respective icon, so that the frontend is not cluttered with too many buttons/sliders.

Details: Currently, the user specifies the axes by clicking on a toggle slider (#7). The goal is to replace this with an icon of the axis, which changes its color when clicking.

User Story: As a mechanically experienced user of the mechanism browser, I want to browse incomplete articles so that I can contribute by adding the missing information to those.

Details: The filter mechanism can be implemented as a tri-state button (complete, incomplete, any) in the search bar.

Progress:

• Backend implementation
• Frontend implementation

Up / Down with arrows

Progress:

• Backend implementation
• Frontend implementation

User Story: As a user of the mechanisms browser, I want to see a visualized summarization of all mechanisms so that I get an intuitive overview of what I can explore.

Details: The final diagram(s) does not need to be implemented in the backend nor frontend. Instead, different diagrams should be plotted as a prototype by, e.g., matplotlib so that we can decide on what to add to the system later on.

User Story: As an expert user of the mechanism browser, I want to be able to extend articles with additional resources so that they contain more valuable information.

Details: These resources should include:

• Images
• Videos
• Use cases (links to applications of the mechanism)
• 3D models

Progress:

• Backend implementation
• Frontend implementation

User specifies vector input and vector output as a query

Behavior: Images that were added via the Django admin interface do not show up in the frontend.

Expected behavior: Images should show up in the frontend.

Proposed solution: The backend could save the images in frontend/public/media/img.

User Story: As a user of the mechanisms browser, I want to see mechanisms ranked by their importance for me so that I find valuable information faster.

Details: The search results should be ranked by these factors:

• How much do they match the search query? (implement metric)
• How much do they differ from the other search results? (implement metric)
• Are they verified? (see #22)
• How good is the user ranking?

User Story: As an expert user of the mechanism browser, I want to add a flag "verified" to a mechanisms article to show other users that it contains useful information.

Details: A filter mechanism can be implemented as a tri-state button (verified, unverified, any) in the search bar.
Optional: Expert users can have an account on which they get kudos -or whatever currency- in return ;)

Progress:

• Backend implementation
• Frontend implementation

would be super cool if we could make a proof-of-concept in Rhino which calls to our search engine and imports resulting 3D models into Rhino. I understand that this is a stretch but it could be cool to think about how to do this and build a bit of a service for it

--presumably Rhino is WAY too complicated, but openSCAD or sth may work out

User Story: As a user of the mechanism browser, I want to see search results that match the specified properties so that I find mechanisms faster.

Details: This is the frontend part of the feature described in issue #4.

when a user searches a mechanism that does not exist yet he gets the question whether he wants to request this mechanism.

That will create a mechanism-request with the given in and output, which can then later be filled in by somebody else

• Backend implementation
• Frontend implementation

• Backend implementation
• Frontend implementation

As a user of the mechanism browser, I want to select rotation and translation axes to easily describe the desired mechanism.

User Story: As a user of the mechanisms browser, I want to search mechanisms just by a part of their name so that I don't have to remember the exact name.

Example: When the user searches for "bevel", "Bevel gears" should be in the results.

Details: The implementation should use a string metric, such as the Levenshtein distance, to also be resistant to typos. Pure substring matching is sufficient for now.

would be cool to just use a URL to a mechanism, crawl relevant information and prefill this into the annotation UI. It would for example take the images from IMG tags and displays the largest one by default. Also the largest amount of uninterrupted text is probably the description, a link to an STL file is probably the 3D model etc.

All the user would need to do is specify the axes of rotation/translation and check the automatic suggestions (overrule where needed). I would be curious to see how far this gets us

I tried to store the transmission of this mechanism and it did not save it, probably formatting error. Two things: 1) I think it would make sense to indicate them as a factor 1:10, 2:15, 1:100 so I would allow for that and translate it however you need it internally 2) I would warn the user when he inputs data that is not coherent with the formatting and thus not saved. Currently I did not know that failed and thus made my last 10 mechanisms without transmission data saved

User Story: As a user of the mechanism browser, I want to see all known details for the search results, so that I don't have to use additional search engines (like Google).

Details: Each search result should show the name and a picture of the respective mechanism. When the user clicks it, a page should open that contains all available information, such as the input, output, and transmission of the mechanism.

often, it is not exactly clear how big the transmission ratio is. It can be precisely calculated but not everybody can do that. There is a clear difference though between 10:1, 1:10, 1:1 and 1:100 which most people will be able to guess. I would thus add a toggle between guessed and measured

As a user of the mechanism browser, I want to see a mechanism so that I get new information.

User Story: As a user of the mechanism browser, I want to see new search results while I am specifying the parameters (e.g., rotation axes) so that I see how these influence the outcome.

User Story: As a user of the mechanism browser, I want to see search results that match the specified properties so that I find mechanisms faster.

Details: The frontend sends an HTTP POST request to the backend, which contains the specified properties (e.g., the input rotations) as JSON a search query to the backend, which contains the specified properties (e.g., the input rotations) as URL parameters (#12). The backend should filter the known mechanisms and send a response with the top 10 matching mechanisms. For debugging purposes, the match score (e.g., a number between 0 and 1) should be also annotated to each of the search results.

As a user of the mechanism browser, I want to have a web frontend so that I can interact with it.

here a sketch:

Behavior: The user can create mechanisms without an in- or output.
Expected Behavior: If the user tries this, the backend should return an HTTP 400 error.

e.g. two gears could have a transmission ratio of 1:5 but and important feature is that the direction of rotation is reversed. Otherwise you may want to have a mechanism like http://507movements.com/mm_034.html

User Story: As a frontend developer, I want to use a templating engine (e.g., Jade), so that I can modularize my code.

User Story: As a user of the mechanism browser, I want it to run on a computer that is not the notebook of a developer so that it is available all the time and from other machines.

Details: Within the HPI network, the mechanism browser should accessible via an URL, e.g., http://mechanism-browser:8080/.

It would be really cool to have a small 3D view showing the selected axes of rotation and translation. Which could then also be modified by dragging these around:

this would give a somewhat more spatial idea of what is going on, could even be a simple animation (!) it also allows to distinguish situations where axes align or not:

• Backend implementation
• Frontend implementation

EDIT: Some requirements were moved to issue #49.

User Story: As a user of the mechanism browser, I want to be able to go back to the search page by clicking a button so that I can conveniently search for another mechanism.

Details: There should be a button (or a clickable logo) on top of each page that is not the search page.

last page link gives item count instead

If something is not there, dont fake it by default. Better is to leave it as so it is clear that things need to be added in here

User Stroy: As a frontend developer, I want to have good code so that I can understand and maintain it.

Details: The frontend should comply with the following coding standards:

• No unused dependencies in package.json
• Consistent indentation
• There should be one .css file for each .html file
• There should be one .js file for each .html file
• Single and double quotation marks should be used consistently
• There should be no js code in .html files
  - There should be no style information in .html files

I happen to know that it is rot rot.y rot.z trans.x trans.y trans.z but any other person would not ;) This is exactly why I would have highlighted icons when one is selected and greyed out ones when they are not selected as I have shown in my initial UI sketches

User Story: As a user of the mechanisms browser, I want to see a visualized summarization of all mechanisms so that I get an intuitive overview of what I can explore.

Details: Reuse the findings of #38.

• Generate tables for diagrams in the backend for all mechanisms. Make them accessible from the frontend.
• Plot the tables as diagrams in the frontend. Send a search query for a part the user clicks on.

E.g., for a mechanism id that does not exist

In general: no field should be required I think

I cannot edit the transmission field anymore ;)

User Story: As a user of the mechanism browser, I want to select/deselect rotation axes with few clicks so that I can specify them faster than by keyboard.

Details: Currently, the user specifies the axes by entering a number with their keyboard into a field. The goal is to replace this field with a button, which has a tristate. It is either:

• Default: Not pressed (gray): A translation on / a rotation around this axis is not specified.
• Pressed once (green): There is a translation/rotation.
• Pressed twice (red): There is no translation/rotation.

User Story: As a user of the mechanism browser, I want the frontend to be self-explanatory and have a pleasant appearance so that I can use it instinctively without a tutorial.