Hi, Thanks for using Zeppelin and considering contributions!
Helium application is designed to download and run user code inside of paragraph in a single (or few) clicks. Customizing Zeppelin UI is not in Helium's scope at the moment. So, using Zeppelin as a backend for your custom UI is valid approach for now. Feel free to create JIRA issue for individual items that you're trying to contribute. So community can see and discuss details of individual items. I think items in your suggested list are valuable. To me 1) and 2) is little bit unclear and if you can share more detail, that would be helpful. Thanks! moon [1] http://apache-zeppelin-users-incubating-mailing-list.75479.x6.nabble.com/Zeppelin-UX-Design-Roadmap-Proposal-tp2803p3007.html On Tue, Jun 28, 2016 at 11:44 PM Apurba Nath <ap.n...@gmail.com> wrote: > Hi > > We love zeppelin and the ease with which we can use it, however building > applications on top of zeppelin poses a few issues as we are unable to > leverage our UI skills as we have to stay within the boundaries of > zeppelin. > > We looked at helium, but we thought it still has the same problems, an > alternate solution which has yielded us good benefits it to use zeppelin > notebook and server as backend and write the UI outside zeppelin. We then > use the paragraph and other apis to run the queries and show results in our > custom UI. This allows the UI to incorporate styles, themes and > visualizations which are more apt to the client needs and still use > zeppelin for the actual data crunching. > > tldr version > The steps that we follow are: > 1. Build a custom UI > 2. Code the actual processing logic in zeppelin and expose this as > notebook, for each of the relevant paragraphs take the paragraph id > 3. UI calls the paragraph and job api to submit queries and retrieve the > results, the apis we mostly use are > run the relevant code with /api/notebook/job/{notebookId}/{paragraphId} > retrieve the results with > /api/notebook/{notebookId}/paragraph/{paragraphId} and parse the result.msg > object and display it in UI > 4. We made some changes to get the paragraph id in the UI easier > 5. We made some changes to return more than just status ok from job api, we > return a id with which the job status and results can be tracked which is > useful in our async responses. > > We can submit all these changes as a patch if the group feels it can be of > value. > > Thanks > Apurba >
