Sole maintainer problem about zebkit

p.s. If (and only if) you were to proceed on my infinitely wise advice, I would volunteer as an evangelist, and/or documentation writer/editor. I write reasonably well and am passionate about good software. If (understandably) you cannot take my advice or prefer to be sole contributor, I hope you'll accept all my thoughts as praise for what you've built and not find me too opinionated :)

[barmalei]

Thank you very much for your point, very good overview that summarizes a lot of thing I have also thought about. Give me time to give you an answer.

[DavidPesta]

Wow, @Jayboyd just did a lot of work to echo and greatly expand upon my sentiments to explain to you exactly what I was wanting to explain in exactly the way that I would have wanted to explain it. Best of all, I didn't need to spend ANY time explaining it because he did it for me. Now THAT is the power of open source! That, paradoxically, is in itself an example of the very thing we are talking about. Don't you love it? :)

[DavidPesta]

By the way, I might also volunteer as an evangelist and documentation writer, maybe even poke at the code a little here and there. So let's get this ball rolling.

[peterkingsbury]

I'd like to chime in with my own thoughts, and play devil's advocate for the sake of stimulating discussion.

• @DavidPesta and @Jayboyd have identified their own fears that the project may fail after they commit to using Zebra 100% for their own projects, due to the fact that there is exactly one maintainer. They've offered to write documentation and become evangelists.
• Currently the documentation is very good; it lacks what any documentation written by a sole maintainer lacks (proofreading by a third party for comprehensive value).
• Currently the feature-set is very good. It can be used as a game framework UI (I can personally attest to this); for Canvas-based UI rendering it offers its feature-set with as much gusto and verve as a UI library could muster.
• Currently the support is very good. @barmalei doesn't possess the overhead of a community, forums, bazillion support emails, attention from script kiddies and V1@gra vendors, and so on. The few times I've engaged him for support, he's been able to respond within 24 hours (I'm in GMT-5, I suspect he's somewhere in the realm of GMT+1 or +2, which IMO makes his average response time exceptional)
• Zebra is not a web app framework, it is not a DOM-based UI framework, and it is not an MV* framework. It shares a commonality with, for example, UNIX tools: it does what it does, and does this very well. Personally, I would not care to see Zebra evolve into a complicated mess of code hierarchy which has little to do with its original design philosophy; when I first approached it, I was able to get past my blocking task quite quickly, because dropping it into my already-existing application just worked.
• For other purposes where DOM rendering is sufficient, there are libraries which exist that have been around for quite a long time, do their jobs quite well, and probably have maintainers a-plenty (I can also personally attest to this, having been a Dojo Toolkit user for years); Zebra exists in a different realm (high graphical-performance UI library), so I don't think it's entirely fair to compare it to, say, jQueryUI, any more than comparing a Mom & Pop Shop grocery -- which offer their own incontestable variety of personal touch and elegance -- to a Walmart megastore.

Does the Zebra library need to grow at this point in time? Unknown. If @barmalei has a customer (read: fervent Zebra user who needs/demands his attention frequently in order to produce code which is being developed on a timeline) then there is a need for support personnel (or a support framework) where he can deal with issues as they come in. At this point, it would be beneficial to have additional support personnel. But achieving competent, experienced support personnel is time-costly, and can't be done with Zebra in its current state. Additional core-dev gurus with PR skills would be the step toward achieving this.

Does Zebra need additional users? For @barmalei's justification of continuing to maintain a project borne out of pure love for development: absolutely. Does it need aggressive marketing, SEO, TV commercials a la GoDaddy, or a spot on SuperBowl? Hyperbole, I know... but no, it doesn't need aggressive marketing -- unless that marketing brings in a customer which will drive the core development and cause core dev gurus to fill up gaps where none have been found before.

Does Zebra need additional free-willed code contributors? Not unless @barmalei is willing to defend against errant code commits, and maintain a high standard that guarantees that the existing community are not turned off to the point that they decide to fork the project.

Does Zebra need a bigger community? I firmly believe that a community size is a merit to the thing by which the community members stand. If Zebra sucked, this forum would be filled with the chirping of crickets. But it's fantastic, and has a thriving group of core opiniates, as well as silent lurkers (a proud group up until today I was a part :-) ). We all use Zebra for our projects (well, most of us ;) ), we all like Zebra, and we all thank you for generously offering your time to make our lives easier. Zebra's community will grow naturally because we talk about it to our geeky friends, who then in turn Google "Zebra UI" and end up here.

@barmalei, if you're going to take steps toward the suggestions mentioned earlier in this thread, I would also urge caution, and suggest moving in careful steps. For example, accepting one contributor to proof-read and clarify the documentation, open-sourcing whatever is not open-sourced, and taking on one additional official contributor (e.g. core dev guru) would go a long way to improving the code base.

It may be as simple as the digital equivalent of sticking a "help wanted" sign out front, and accepting contributions after carefully weighing their impact. But Zebra is what it is today because you were doing what you do best. Continue to do that, and Zebra will continue to be great.

@peterkingsbury - All excellent points. If I were Andrei, I would feel torn (and probably would not take my advice for the reasons you mention). I agree a stepwise, very measured approach would be wise. As you suggest, someone to proof/edit the great existing docs. Or maybe to do a migration to GitHub pages (or maybe that's undesirable).

To be clear, I am not advocating PR and being on the map with other big libraries/frameworks so that Zebra could have glory and fame. I don't generally admire such things or aspire to them myself. I was saying more that Zebra fills a niche which is otherwise unfilled, and many developers don't know it exists but would be happy to discover it. So I am advocating those things that increase its visibility for the benevolent purpose of advancing the cause of rich GUIs on the web stack.

It's interesting you say there is a community. I see there is activity here, and a bit on Zebra's website, but it would go a long way to have a wiki or forum or mailing list. Case in point, why is this discussion happening here? Search StackOverflow for Zebra. It's as if it doesn't exist. I completely agree that Andrei's work and level of support is amazing, but it is no match for an active community that is aware that there is a community.

You raise valid reasons to avoid the pitfalls of ramping up an open source project. As passionate as my argument may be, I'm honestly not familiar with the ins and outs of running an open source project with multiple contributors, so it's informative to read your perspective. As @DavidPesta said, this conversation is an example of the benefits of opening up to community input.

If you've made apps with Zebra, can you share links? Maybe just including some showcase/demos in the main README would be of value. For me, seeing what others have done adds confidence in the technology and can give the feeling that there may be others who can answer questions if I dig into it.

[DavidPesta]

Once again, @Jayboyd answered sufficiently and I don't have much to respond. When I said "documentation" and "evangelist," I was using language that @Jayboyd had used on the tail of my humor about his post being in and of itself what his post was talking about by way of him explaining everything instead of me. But in fact, with my use of that language, what I had in mind was the writing of demos and tutorials on a website (roughly documentation so to speak) and solving people's problems on StackOverflow using Zebra as a solution (evangelism). Both of those things @Jayboyd mentioned just now in his most recent response, which makes me suspect we're all on the same page.

For the record, I don't want to make a promise yet about any commitments because, after reviewing my availability, I won't be able to start on this activity until late this year. But I am thrilled about this project and what it means for the future of web development for those who adopt it for their projects. It will be fun to be a part of helping this grow in the long term.

[barmalei]

Thank you Guys again for all the good words and suggestions. That is great Zebra project catches your attention and the attention is transformed into number of clever remarks, recommendations and calm words (that works like a fuel for me:)).

The aim

Your understanding of strong and weak sides of the project is very clear. The strong points determine the target(s) the project tries to archive. Let me start from the depicting the target: zebra tries to bring well organized, structured, re-usable, less costly in development and support approach of Rich WEB UI (including mobile) applications creation. I think that doesn't sound new for you, but anyway the statement is important to be mentioned. Everyone who has been involved in implementation of WEB based Rich UI met "Devil", everyone who has done it for mobile devices met "Devil" twice. Zebra tries to kill the "Devils", making WEB development closer to software engineering. As you can see the project aim is quite general and as result ambitious. Zebra adds own OOP implementation, almost ignores CSS and DOM existence, re-implements from scratch substantial bunch of UI components and so on.

The way

From my point of view, the way zebra should be pushed ahead, acquires community and proves its concept is consuming the solution in real projects. This is the place where zebra as a new general and ambitious solution clashes the real practical world. People want to see project portfolio and be guaranteed to have a deal with stable well done product with big community, especially when the solution slightly reconsider "WEB development traditions". At the same time zebra needs be used in customer projects to gain all the things customers like and want to see. Start walking on the cycle.

At this particular moment my expectations to find a project(s) that can be a good ground and use-case for zebra growing don't come to true. But I still consider it as the most realistic opportunity to change significantly the situation with zebra development:

• It should let me spend much more time with zebra (not only share my free time)
• It helps to get community, since people start trusting the approach
• It catches other projects where zebra can be useful

I very appreciate proposed help, but I don't think it changes situation significantly. Also not sure investing time and resources in building zebra community is workable thing. Zebra is already open source project what means contributors are welcome. Nobody prevents people from doing the project better by sharing their ideas and suggestions with me.

Viability

Important subject that explicitly or implicitly is kept in people mind is whether zebra viable approach. To be honest this is also a question for me (probably I should not say it :)). When I had started the project I was practically sure it would workable in WEB, since zebra was not developed from scratch, zebra was a conversion (by implementing a special Java to JS converter) of multi platforms UI project (lwvcl) that could work on J2EE, J2ME, SWT(Eclipse), .NET platforms following common approach and had real customers.

Browsers and mobile platforms "Zoo" weird bugs, specific features and behavior has (slightly:)) shaken my convictions in zebra. The multiple browsers and mobile platforms support steals too much time, more than I have expected before.

Nevertheless there are few not too bad example of zebra usage:

• Application that shows different views of file archive stored in MongoDB: http://virtual.jnc.nl:8888/dms/
• Sometimes zebra is used for building mockup application: http://virtual.jnc.nl:8888/dms/mock.html

Plan B

will later state few alternative points of future zebra development ...

Neither of the links work for me on Mac OS X Chrome 33. I get this:
Uncaught TypeError: Object [object Object] has no method '$new'

Actually several of the demos on the main Zebra site do this, but oddly if I reload they will sometimes load. Seems like a race condition, maybe not waiting for all scripts to load?

I'm glad to have sparked a conversation. I appreciate your openness about pros/cons of the project, viability, etc. All makes sense. I know I've expressed a lot, but just feel like commenting -- I think there are JS frameworks that support high quality engineering, and the whole ecosystem is maturing. It's debatable as you say whether Zebra supports this or not as it was not designed with the crazy multitude of platforms including mobile, but it is compelling in its architecture: coherence, flexibility, familiarity to Java/.NET world. Mobile/web cross-platform is a big thing, and the rage these days seems to be "responsive" design -- layouts that adapt to lots of viewport sizes, touch/mouse behaviors seamlessly working, scalable vector graphics, familiar look and feel on different devices. Zebra, because of its history, had none of these things in mind and so maybe that's a significant weakness. However the thing that stands out to me as unique, and how I stumbled on it, is the ability to do pixel-perfect rendering, with the performance possible with the canvas approach, but also have a complex GUI toolkit using the same approach. How beneficial this is in practice I don't know, but I don't see any other frameworks that exist to do this.

So that's not me arguing for any change in your efforts. Just wanted to clarify what seems unique about Zebra.

I'm curious, what sorts of issues have you run into specifically with mobile devices? I would imagine there are many hurdles, but have you had trouble with performance? Look and feel or layout issues? Android back button? Font consistency? Have you ever tried throwing it into Cordova or PhoneGap?

[barmalei]

The issue that you have is exactly what I described as weird browsers issues. In your particular case this is Chrome bug ! Find more info following the link below:
http://stackoverflow.com/questions/21206676/chrome-32-0-1700-77-function-with-empty-name-causes-something-very-weird

Actually I have fixed the bug in my local Zebra version I am developing right now. I will update the demo with the latest version soon and let you know.

Mobile generates different kind of problems. For instance, on iPad retina switching to landscape mode causes significant performance degradation. The reason is 1pix. Making width 1 pixel less solves the issue. As far as I understand it happens because the picture (in landscape mode) cannot be placed in video memory :) One more issue is IE10/11 (in the same time everything works in IE9) can fill canvas area without respecting clip area you have set. It happens if your try to clip none-rectangular areas. In general performance is not an issue on mobile devices, I could start zebra even on old iPhone3 (not GS), layout also looks okay. I have not tried neither Cordova nor PhoneGap by myself, but PhoneGap has failed for on of a project in the company where I am working now, we switched to JQuery Mobile (personally I find it crappy, but this is practically the only choice among other open source frameworks). The main problem zebra meets is bugs in HTML and HTML Canvas implementations what forces me to first spend time to investigate it and than find a workaround.

[DavidPesta]

I was able to access those two links and play around with them. Like your demos, they show exactly what makes me so interested in Zebra. Every time I come back, I keep loving this project.

It looks like there are two main points you mentioned to helping Zebra flourish:

1. More people using it to build more projects to prove that this works.
2. Support for multiple browsers and multiple platforms.

It seems to me that both of these issues can be solved by having a more cohesive community of smart people in the ecosphere working on those two points. More hands at work on focused goals get more done more quickly. @peterkingsbury warned against the pain of defending against errant code commits to keep a high code standard, etc. But I think that was the original point that @Jayboyd was making in his original post: you may need to deal with the politics of different opinions and such, but in the end you will get a whole lot of progress and things fixed that would otherwise take 1 person too long to handle.

Here are some random ideas that could help galvanize the community toward fulfilling the two points:

For number 1 above: Have a prominently displayed place on your website that showcases other developer's projects and create a really easy way for developers to fill out a small form to submit their project with a thumbnail image, etc. You may be surprised what kind of things are developed by silent lurkers out there like @peterkingsbury who may be interested in having their project appear on the site to help promote ZebKit as well as their own project. This may seem like a catch-22 if you don't have anyone's projects to display yet. So you could start by putting a large banner that says, "Calling all developers! We are looking to feature your project as an example of how ZebKit can be used in real world projects. Click here to submit your project." Or something like that. And of course, you could start by showcasing those 2 links that you just posted! (The ones at virtual.jnc.nl)

For number 2 above: You could identify a dozen of the top issues that are a pain for you to think about dealing with that would take you too much time, write a thorough description of those things that other developers can understand and think about. Display a call for help on your website that links to a special web page that shows a short summary of these issues in like a table or grid (they can click on the issues to view the thorough descriptions) and color code the progress toward getting those issues dealt with. (I would even allow people to attach discussion thread comments directly to these displayed issues, "14 Comments, Click to View".) It's using your website to get the community directly engaged in fixing specific problems. Yes, that may cause certain people to become scared to see that "there are still problems being worked out" but the more mature developers who you are mostly interested in will already understand that the project has problems. This will actually increase confidence in those kinds of developers that serious attention exists to solve these problems and that the project is moving forward. Even at the very beginning before you get anyone to help you, it will create an impression that the community is involved. This attracts people and some of them will stick around to help because their efforts are coordinated and organized for them.

There's real psychology involved behind every successful project. If you can simply make the place "look" like there is community participation, people will be drawn to the project, and before you know it there will actually BE community participation. You just need to get community mechanisms in place.

There's an up-front investment of your time to build a stronger community, but it will pay off as dividends in much bigger ways over time.

Anyway, those are 2 ideas. I'm sure there are dozens more.

[barmalei]

@Jayboyd
have just fixed problem with demo/mockup apps, should work now.

[barmalei]

@DavidPesta , @Jayboyd , @peterkingsbury
Meanwhile the new zebra version (4.2014) is almost ready, at least it is in repo right now, what can be interested for you is mobile demo application. Load it on your device following the link below:

http://repo.zebkit.org/dev/samples/mobile.grid.html

What it demonstrates:

• Inertial scrolling over the grid component
• Two finger touch and un-touch (the same like you do on laptop with touchpad) on grid component triggers context menu showing. You can navigate over the menu by dragging you finger up and down.
• Touch "T" button (located at the left side) and keep you finger on it. After a while a tool tip will be shown
• Touching bottom text field will bring to showing virtual keyboard, you can start typing a text

Let me know if you have a problem with it :)

[swstudios]

Hi Andrei,

This looks really great. I'd been awaiting text inputs on mobile, and this is just what I needed. Everything worked except the tooltip widget on the left; a touch held there for 5+ seconds resulted in nothing occurring.

(I'm using Chrome 33.0.1750.136 on a Samsung Galaxy Nexus with Android 4.3.1 in CyanogenMod kernel 3.0.72)

Thanks for all your great work! I'll be looking into 4.2014 this week.

• Peter

Andrei Vishneuski [email protected] wrote:

@DavidPesta , @Jayboyd , @peterkingsbury
Meanwhile the new zebra version (4.2014) is almost ready, at least it is in repo right now, what can be interested for you is mobile demo application. Load it on your device following the link below:

http://repo.zebkit.org/dev/samples/mobile.grid.html

What it demonstrates:

Inertial scrolling over the grid component Two finger touch and un-touch (the same like you do on laptop with touchpad) on grid component triggers context menu showing. You can navigate over the menu by dragging you finger up and down.Touch "T" button (located at the left side) and keep you finger on it. After a while a tool tip will be shownTouching bottom text field will bring to showing virtual keyboard, you can start typing a text

Let me know if you have a problem with it :)

—
Reply to this email directly or view it on GitHub.

[DavidPesta]

That's really good!

Also, I came across this yesterday on a site and I had Zebra in mind when I saw it: http://foundatypo.com/demo
It would allow visitors to help with some of the language with minimal effort.

[barmalei]

@DavidPesta
hope web site works with better performance now, have changed hosting plan today.

Hey, glad to hear update. I've had to backburner looking more at Zebra given my focus, but still hope to make use of it down the line. A couple slightly open-ended questions that would matter to me:

Do you think Zebra introduces any performance concerns for an app that might do heavy animation, audio processing, or such? I am working on an app that does some canvas animations and uses WebAudio, all performs quite well but I am having to regularly profile and optimize to keep it that way on my low-end target of iPad 2. For similar apps I would always worry about the memory and CPU overhead of any framework.

I know Apple can reject apps from the app store for all sorts of reasons, often fairly arbitrary, and sometimes this includes apps not having enough of a "native" L&F. Not necessarily that they don't look like iOS apps, but that they don't look like mobile apps. E.g. too "webby". Have you had any experience with Zebra apps made for iOS? Do you think the theming/skinning capabilities make it easy to make an app look like a mobile app?

Your demo looks pretty mobile-friendly. If I had good faith that the answer to both my questions was "sure, go for it!" I might have opportunity sooner than later to try it out. That said, my current project can't afford such experiments, and I need to see it to a good point.

[barmalei]

@Jayboyd
Performance. From one hand I have spent a lot of time to make source code as much performance as I can. For instance, I try to avoid unnecessary object creation, mouse (touch) events are share the same object, layout managers, borders, etc are shared between components. Try to avoid calling function in critical, extensively used part of code (even if it requires copy paste) and so on. From another hand I still see space for performance improvements. You can take a look at few video playing zebra samples as an illustration of zebra performance:
http://repo.zebkit.org/dev/samples/videoplay1.html
http://repo.zebkit.org/dev/samples/videoplay2.html

Apple look and feel. Don't have an experience with building apple-like look and feel. But in general zebra allows developers to render everything what they want. I even have seen some implementation of Apple-like zebra buttons. An application look and feel customization is supposed to be done with zebra JSON configuration.

Anyway I cannot promise Zebra is something you need. I do my best to make the project better, invest a lot of time (probably too much) to gazing to source code to make even small things better. Also I try to make one the first JS project that makes possible:

• Read source code
• See clear components model
• Extend source code on OOP level

Look at it by yourself and make your decision :)

Thanks Andrei. Yeah I'll have to look for myself at some point.

[visionscaper]

Hello,

I'm looking for a library that can draw user interfaces on a canvas which can then subsequently be used in a rendering of a Virtual Reality environment. So, this library seems to be spot on!

The WebVR API currently assumes that everything is rendered on a canvas, so 2D UI elements, that are for instance projected on the surface of a 3D object in VR, also need to be drawn on that canvas.

To me, this is the 'killer' application of this library. :D

However, I'm wondering to what extend it is still actively maintained?
And, is there still a sole maintainer? Nobody can scale him/herself enough to do everything on his/her own in such a project, especially considering all the different platforms it should work on!

Kind regards,

-- Freddy Snijder

[barmalei]

I am actively working on the next generation of the approach. Zebra as a first iteration has helped to discover many things, especially regarding complexity of WEB standard world. The main cause of the complexity is not standard itself, but implementations and interpretations of these standards by different vendors. The next generation of zebra is called "zebkit", it has been significantly re-worked regarding many aspects:

• OOP concept simplification. This the basement of zebkit "building".
• Integration of DOM element in general and canvas elements in particular has been practically completely re-done. Now it is possible to add DOM element in zebra layout and (what especially important for better performance and VR) it is possible to develop complex UI components on own separated HTML canvases. It speeds up rendering because of decreasing repainting overhead.
• Input events unification. Very important thing that helps to treats input events from different devices following one common approach (mouse, touch, pen as one type of event).

And many many other changes and updates.

I am planning to host zebkit in new repo (zebkit), since number of changes it have got very significant. Actually it is next generation of zebra that follows the basic idea, but does it much better (from my point of view:)).

Soon I will publish the new static generated website with kick-off information and examples of zebkit. Now you can see only logo following the link below :)

https://github.com/barmalei/zebkit

And yes, I am still sole dev. But this can be also changed soon.

[DavidPesta]

This continues to be amazing work! Good job!