Minor Changes
Functionality
- Fluency should provide templates that the user can use directly to speed up the process. (5 votes)
- Have a most used widget area. It will list widgets that have been used that session so the user can easily grab them from the top of the list instead of searching again.(5 votes)
- Enable all Menu items
a. Help does nothing
b. Windows->Options loads black, empty dialog
c. File->Save As a Molecule does not work
(3 votes) - Improved widget finder which will arrange different widgets according to categories. (2 votes)
- Personas/workspaces/profiles would help usability and productivity. Maintain work patterns, menu order-lists, and other preferences for each project. (2 votes)
- The properties menu needs to be more responsive when a widget is selected. (1 vote)
- Fluency should provide many widgets that are frequently used. Eg. Sliders , Scroll bars , Tab Widget Containers, Tree menus etc.(1 vote)
Usability
- Tools need configurable shortcuts; switching between selection, text, and connection tools is cumbersome and usually happens every few seconds. (e.g. 'S'> selecticon, T'> text icon, C'> connection widget icon, and ...)(5 votes)
- Different views of widget list:
a. Organize widget pallet according to persona usage.
b. Organize widget harbors the same way (e.g. simple button->input->clicked ought to be immediately recognizable and on the first page of harbors).(4 votes) - Some notation on GUI need to be changed. using more friendly common name. (e.g. Instead of 'Plugins > Engine', for example, 'Tool > Build' or 'Run > Build' could match well to users expectation.(3 votes)
- Widget properties window isn't very useful, and on my PC wants to dominate the foreground with or without focus.(1 vote)
- Warn the author of illogical connections. This will maintain the author friendly environment where the author is in control but also help them possibly catch their mistakes.(1 vote)
Codebase
- Conformation of code convention is required. e.g. Various type of bracing('{}') way, indentation and etc harms readability. (5 votes)
- Widget library ought to be more dynamic. There should be an option to download widgets from a repository, or at the very least, the code should support the addition of such a feature.(3 votes)
- The primary fluency frame does some non-GUI-like things.(3 votes)
- Improved package structure. The highest level packages make sense: editor, engine, media, shared but the packages directly under editor and engine seem convoluted.
a. Could perhaps add a shipping package in engine, under which all shipping related packages reside, rather than directly under engine.
(3 votes) - And finally, shouldn't we go ahead and use similar application available and try analyzing Fluency's shortcomings or strengths relative to others.(2 votes)
- Refactor methods with names better elucidating their function. Good example (toXML() and appToXML()).(2 votes)
- Consider finding a more straight-forward way to add harbors to widgets than the current approach - not sure what that would be yet but the current way seems unnecessarily counter-intuitive.
a. In addition, code is suppressing warnings about the way ships are triggered (maybe this is not a problem but seems unreasonable to have to add @SuppressWarnings("unchecked") to every harbor.trigger() method.
b. If a programmer makes a mistake and tries to access an output/input dock by name (it is a string) which does not exist, a null pointer is thrown and not handled.
(2 votes) - The problem with the getCargo method of InputDock needs to be looked upon. As discussed in the class, there seems to be no difference in the way Fluency treats a ship carrying a null value and the ship queue which is empty.(2 votes)
- The help system in the Fluency application should be powerful enough for the new users to go ahead and experiment with the application.(2 votes)
- Improved logging (lots of System.out)(1 vote)
- Strong naming policy is required. Most of class names and method names are good. However, some names of argument list are remaining meaningless. (difficult to trace meaning of the arguments before entire scanning of the method)(1 vote)
- Elimination of code redundancy. Useless code statement (not affecting on fluency program) or in-block comments.(1 vote)
- Test coverage is still lack. Unauthorized(untested) classes or functions are required to be tested.(1 vote)
- The Test Cases for the project can actually help a programmer in a better understanding of the application. The number of test cases should be increased as well as those test cases should cover varied types of classes.(1 vote)
- Find a better way to test widgets. Current approach is brittle (especially as it related to Harbors).
a. for the most part, in reality, what is tested is that harbors were added in a specific order to the collection.
(1 vote)
Website
- A "suggestion box" for improvements that we haven't thought of.(4 votes)
- Forum where users can ask questions and developers answer. It is a proven fact that such forums are a backbone of any successful open source project. e.g. Java (or suggest their specific function to wish function list,(like JSR of Java)(3 votes)
- source clearly visible.(3 votes)
- The website should have links or tabs which categorize as well as separate the information that is helpful for the authors from the information that is only relevant to the programmers.(3 votes)
- News section. New features(2 votes)
- Wiki -What aspects of the wiki do we need to change?(2 votes)
- FAQ on the opening page.(2 votes)
- Add architectural overview with UML diagrams.(2 votes)
- Consider not making the wiki the primary website but instead link to it off of a main Fluency branded page.(2 votes)
- A large flashy download button like the one found on the firefox website.(2 votes)
- Better description of Fluency (aimed at people unaware of what Fluency is).(1 vote)
- downloads for binaries.(1 vote)
Documentation
- Create a more precise and formal design document as well as formal architectural diagrams (UML)(5 votes)
- Those require being concise and accurate. And also they have very slow steps. For example, there's miswriting in Tutorial.(textfield -> textbox) Authors might waste time to find a specific widget in the name of 'textbox' on Widget Finder, instead of using textfield or textarea.(4 votes)
- Flash Demo would be very desirable for video type documentation. Please watch this tutorial movie. example of ASF+SDF meta-environment
(4 votes) - Fluency website should take the user, especially the authors, on a guided tour that tells them about Fluency application. Also it should present them an easy tutorial about how to develop some simple applications. The video currently included in the website which shows how to build a P2P chat client is an example which is too difficult for non programmers to get. We should focus more on details in tutorials rather than giving them a demonstration about the speed with which the applications can be made.(3 votes)
- Improve the How To Make your first Fluency Widget tutorial.
a. Rename it to How To create your first Fluency application
b. Add screen shots and/or images to support the text
c. Add a java webstart link for a demo example of the application described.
d. (NOTE FROM GJER): here is the current (may '07) one, the previous one and its companion (from dec '05) is far better written, but is now obsolete because the implementation changed radically last october. here are some thoughts on how the new architecture (harbors, docks, ships) should be implemented (from sept '06). of course, what happened after that is a different story. mark's blog and dennis's blog are also useful. NOTE ALSO: i found those with google. the wiki is actually quite large and there's much here (for example: putting a grid on is not a new idea), i suggest that you consider googling at least a little within the site if you have a question as a first step.(2 votes) - Add tutorials on how to link widgets, paint things (not sure if this even works), use text, etc.(2 votes)