Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some thoughts upon a Derby remake #54

Open
cjblomqvist opened this issue Jun 25, 2012 · 0 comments
Open

Some thoughts upon a Derby remake #54

cjblomqvist opened this issue Jun 25, 2012 · 0 comments

Comments

@cjblomqvist
Copy link

I believe the following would be a good base for a specification of a remake of the Ninja UI into a Derby component library:

Browser compatibility
Based upon majority usage, not all inclusive.

My suggestion is:

  • Desktop: IE8+, latest FF, Chrome, Safari
  • Mobile: iOS5+, Android ICS stock browser+, WP8+
Usability
Really good and intuitive

Compared to the rest of my points where I believe it's better to leave quite a lot (of people) behind, I think this is one area where it would be beneficial to make sure to put some extra effort in. My suggestion is:

  • Good keyboard support
  • Good touch event support
  • Progressive enhancement - controls should work decent even without JavaScript. Not because JavaScript won't be available in the target browsers, but because A: it'll support a better pattern of writing code and will be easier to implement into existing applications (one can become so frustrated with using libraries where one cannot use normal features, like submitting a form through a click because the "button" is actually an a-tag), and B: it'll, I believe, make it easier to maintain in the long run . Also, this is right in line with Derby's aim and structure.
  • Because of above, it'll most likely also be easier to achieve support for screen readers and such. A decent support for less capable people will be a huge win (I'd rather pushing people to update into a newer version of their browser than expecting blind people to suddenly be able to see).
  • HTML-wise, not too expressive, but not necessarily minimalistic either (rather focus on functionality, simplicity of CSS and usability in general)
    Another win with a good, standard-like way, which works okay with or without JavaScript, is that it's way easier for others to use your site for various reasons (SEO, other usage of data-mining).
Design / CSS / Effects
Great and intuitive, slick. Really critical.

I think this will be the most critical point for success. Whether we like it or not, without a good design, anyone will almost instantly shrug away. Also, then the developer using Ninja UI will have to do so much more him/her-self. Secondly, a good code simple, quite small, structure for the CSS is also critical. Preferably using something like LESS or Stylus where mixins and variables produces a good structure. Then, implicitly, Ninja UI will be way more customizable than most libraries/frameworks because it will be easy for anyone to go straight into the code and change what they want. CSS is not complicated. Neither is LESS or Stylus. A themeroller way of thinking easily produces extra code, which really is the opposite of customization with this point. Also it's way more complicated to keep up to date, both as a developer of and using Ninja UI.

To summarizing my suggestions:

  • Simple, well structured, quite small, code base
  • Excellent default design
  • Using something like LESS or Stylus with mixins and variables
  • Never let any thoughts of having a themeroller in a negative way affect above points
Functionality
Find a balance between how many components and how much each consist. Never loose sight on above points.

My suggestion here is to:

  • Rather do one thing a 110% great from above points than trying to add functionality
  • Not all inclusive - rather build a good standard functionality which is relatively easy to extend
  • Find a balance between functionality in terms of macro and micro - meaning how many different components you will provide each version compared to how customizable and all inclusive each component is
  • Good code structure with a good philosophy behind it, which together with not making it all inclusive will make it quite easy to understand, change and extend existing functionality. Not critical, but at least aim for decency.
In general
Tests and Derby's philosophy are nice things to have. Speed must be 90% excellent.

Also, I suggest to keep in mind the following:

  • Always keep performance as a priority - performance and speed is critical to usability. This includes size, number of files, JavaScript speed, etcetera. Note that this doesn't mean the code has to be a 100%. Rather I'm a firm believer that 90% better performance can be done at 10% of the time it takes to make something a 100% speedy. Don't waste time but make sure it's good when it comes to performance and speed.
  • A decent test suite would be nice, which will ensure longevity and keep developers from becoming frustrated with simple bugs appearing repeatedly with new versions. Not necessary at first though.
  • Try to adhere to Derby's philosophy of development as much as possible

Anyway, just my 5 cents. Feel free to let me know your thoughts. I'd happily contribute work if I sense above direction is in line with the remake.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant