Re: Project Fauxton Feedback
Hi Eli, you can try to modify [1] and [2] Happy hacking, Robert :) [1] https://github.com/apache/couchdb-fauxton/blob/5de1fe6682fc5a9dee44022498357febd73c3600/settings.json.default#L67 [2] https://github.com/apache/couchdb-fauxton/blob/730e856dcc6f8716e1a797d6bf0fabe27a62cbc9/tasks/helper.js#L17 On Thu, Sep 17, 2015 at 9:34 PM, Eli Stevens (Gmail) wrote: > Is there a recommended way to `grunt couchapp_deploy` to a non-local > CouchDB instance? None of our DB hosts have git installed (meant to > match our production deployment hosts in terms of installed packages, > so we explicitly don't want git there). > > Alternatively, is there a way to get fauxton master without having to > keep a local repo up to date? I know that bower can interact with > github directly, but I'm not sure if there's something similar for > npm. > > Cheers, > Eli > > > On Thu, Sep 17, 2015 at 9:26 AM, Michelle Phung > wrote: > > Hi Eli, > > > > We don’t use a schedule for the NPM package or Fauxton releases. The > reason being is because we enjoy being able to fix bugs and merge them, and > have that code be the latest code everyone works off of. The master branch > moves FAST, from my point of view. Fauxton comes standard shipped with > CouchDB, and that is considered the latest stable tested release. The NPM > Fauxton package is a fairly new development for us, but auxiliary to all > the other things we have to do :) > > > > Unfortunately, the npm package fauxton@1.0.3 is a bit outdated (4 > months), and we haven’t integrated a work flow that updates it every time > we commit a fix, but I will bring that up moving forward for us. > > > > I am going to bug Robert K. to show me how to update the node package > tomorrow, and so it should be updated soon! hopefully it’ll be available > over the weekend/next week for you guys. > > > > Try the github repo in the meantime though! > > > > :) > > Michelle > > > >> On Sep 16, 2015, at 8:32 PM, Eli Stevens (Gmail) > wrote: > >> > >> I just (mostly) followed the instructions at (except for the -g part, > >> since I didn't want it global): > >> > >> https://www.npmjs.com/package/fauxton > >> > >> And ran the following: > >> > >> npm install fauxton > >> cd node_modules/fauxton/node_modules/.bin/ ; ./grunt couchapp_deploy > >> > >> Which had references to "fauxton@1.0.3 node_modules/fauxton" in the > output. > >> > >> Does that answer the question? > >> > >> Aside, is what I did the best way to get a mostly-stable version of > >> fauxton? I assumed that would be more stable that pulling directly > >> from git. This goes back to my earlier question about releases; it's > >> not clear what the best way to get something new and usable is. > >> > >> Thanks, > >> Eli > >> > >> On Wed, Sep 16, 2015 at 3:06 PM, Michelle Phung > wrote: > >>> Hi Eli, > >>> > >>> JIRA is the place for bugs. > >>> > >>> Its kind of tough to get people to look at it though, since there’s a > lot going on with JIRA, and its a little endless. > >>> > >>> I thought we fixed the problem you described though. > >>> Did you pull from https://github.com/apache/couchdb-fauxton, the > master branch? > >>> > >>> Michelle > >>> > >>> > >>> > On Sep 16, 2015, at 5:50 PM, Eli Stevens (Gmail) < > wickedg...@gmail.com> wrote: > > Where is the appropriate place to file bugs against Fuaxton? Most > recent I see in JIRA is Feb. 15th of this year. > > As of a couple of hours ago when I updated my install, the view query > options UI wasn't respecting start and end keys (though the link to > the raw JSON is correct). > > On Wed, Aug 19, 2015 at 11:34 AM, Eli Stevens (Gmail) > wrote: > > I agree with kexpal's comment on the PR; large documents would make > > this very, very painful. > > > > I was asking for a view checkbox that would result in a 3rd column > for > > view results (key / value / optional doc) that defaulted to off, so > > that I could include it when appropriate. > > > > Cheers, > > Eli > > > > On Wed, Aug 19, 2015 at 8:26 AM, Robert Kowalski > wrote: > >> Thank you for your feedback! > >> > >> Based on the feedback we will try to enable `include_docs` per > default: > >> > >> https://github.com/apache/couchdb-fauxton/pull/499 > >> > >> What do you think? > >> > >> On Wed, Aug 19, 2015 at 9:55 AM, James Dingwall > >> wrote: > >>> Eli Stevens (Gmail) wrote: > > On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall > wrote: > > > > I get the impression that more whizzy effects (fade in/out, > sliding divs > > etc) have been added which don't play nicely with remote > sessions with > > low bandwidth so a preference to use more basic transitions > would be > > useful. > > +1 > > Note that it looks like the mailing list strips screenshots, so > you > might need to host-and-
Re: Project Fauxton Feedback
Is there a recommended way to `grunt couchapp_deploy` to a non-local CouchDB instance? None of our DB hosts have git installed (meant to match our production deployment hosts in terms of installed packages, so we explicitly don't want git there). Alternatively, is there a way to get fauxton master without having to keep a local repo up to date? I know that bower can interact with github directly, but I'm not sure if there's something similar for npm. Cheers, Eli On Thu, Sep 17, 2015 at 9:26 AM, Michelle Phung wrote: > Hi Eli, > > We don’t use a schedule for the NPM package or Fauxton releases. The reason > being is because we enjoy being able to fix bugs and merge them, and have > that code be the latest code everyone works off of. The master branch moves > FAST, from my point of view. Fauxton comes standard shipped with CouchDB, > and that is considered the latest stable tested release. The NPM Fauxton > package is a fairly new development for us, but auxiliary to all the other > things we have to do :) > > Unfortunately, the npm package fauxton@1.0.3 is a bit outdated (4 months), > and we haven’t integrated a work flow that updates it every time we commit a > fix, but I will bring that up moving forward for us. > > I am going to bug Robert K. to show me how to update the node package > tomorrow, and so it should be updated soon! hopefully it’ll be available over > the weekend/next week for you guys. > > Try the github repo in the meantime though! > > :) > Michelle > >> On Sep 16, 2015, at 8:32 PM, Eli Stevens (Gmail) >> wrote: >> >> I just (mostly) followed the instructions at (except for the -g part, >> since I didn't want it global): >> >> https://www.npmjs.com/package/fauxton >> >> And ran the following: >> >> npm install fauxton >> cd node_modules/fauxton/node_modules/.bin/ ; ./grunt couchapp_deploy >> >> Which had references to "fauxton@1.0.3 node_modules/fauxton" in the output. >> >> Does that answer the question? >> >> Aside, is what I did the best way to get a mostly-stable version of >> fauxton? I assumed that would be more stable that pulling directly >> from git. This goes back to my earlier question about releases; it's >> not clear what the best way to get something new and usable is. >> >> Thanks, >> Eli >> >> On Wed, Sep 16, 2015 at 3:06 PM, Michelle Phung wrote: >>> Hi Eli, >>> >>> JIRA is the place for bugs. >>> >>> Its kind of tough to get people to look at it though, since there’s a lot >>> going on with JIRA, and its a little endless. >>> >>> I thought we fixed the problem you described though. >>> Did you pull from https://github.com/apache/couchdb-fauxton, the master >>> branch? >>> >>> Michelle >>> >>> >>> On Sep 16, 2015, at 5:50 PM, Eli Stevens (Gmail) wrote: Where is the appropriate place to file bugs against Fuaxton? Most recent I see in JIRA is Feb. 15th of this year. As of a couple of hours ago when I updated my install, the view query options UI wasn't respecting start and end keys (though the link to the raw JSON is correct). On Wed, Aug 19, 2015 at 11:34 AM, Eli Stevens (Gmail) wrote: > I agree with kexpal's comment on the PR; large documents would make > this very, very painful. > > I was asking for a view checkbox that would result in a 3rd column for > view results (key / value / optional doc) that defaulted to off, so > that I could include it when appropriate. > > Cheers, > Eli > > On Wed, Aug 19, 2015 at 8:26 AM, Robert Kowalski wrote: >> Thank you for your feedback! >> >> Based on the feedback we will try to enable `include_docs` per default: >> >> https://github.com/apache/couchdb-fauxton/pull/499 >> >> What do you think? >> >> On Wed, Aug 19, 2015 at 9:55 AM, James Dingwall >> wrote: >>> Eli Stevens (Gmail) wrote: On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall wrote: > > I get the impression that more whizzy effects (fade in/out, sliding > divs > etc) have been added which don't play nicely with remote sessions with > low bandwidth so a preference to use more basic transitions would be > useful. +1 Note that it looks like the mailing list strips screenshots, so you might need to host-and-link them. >>> >>> Thanks Eli, I didn't notice that when I received a copy of my post. I >>> have placed my unchanged comments and screen shots in a github gist >>> available from: >>> >>> https://gist.github.com/JKDingwall/6b2a6377d94a83ea5d63 >>> >>> >>> James >>> Zynstra is a private limited company registered in England and Wales >>> (registered number 07864369). Our registered office and Headquarters >>> are at >>> The Innovation Centre, Broad Quay, Bath, BA1 1UD. This email, its >>> contents >>> and any attachments are co
Re: Project Fauxton Feedback
Hi Eli, We don’t use a schedule for the NPM package or Fauxton releases. The reason being is because we enjoy being able to fix bugs and merge them, and have that code be the latest code everyone works off of. The master branch moves FAST, from my point of view. Fauxton comes standard shipped with CouchDB, and that is considered the latest stable tested release. The NPM Fauxton package is a fairly new development for us, but auxiliary to all the other things we have to do :) Unfortunately, the npm package fauxton@1.0.3 is a bit outdated (4 months), and we haven’t integrated a work flow that updates it every time we commit a fix, but I will bring that up moving forward for us. I am going to bug Robert K. to show me how to update the node package tomorrow, and so it should be updated soon! hopefully it’ll be available over the weekend/next week for you guys. Try the github repo in the meantime though! :) Michelle > On Sep 16, 2015, at 8:32 PM, Eli Stevens (Gmail) wrote: > > I just (mostly) followed the instructions at (except for the -g part, > since I didn't want it global): > > https://www.npmjs.com/package/fauxton > > And ran the following: > > npm install fauxton > cd node_modules/fauxton/node_modules/.bin/ ; ./grunt couchapp_deploy > > Which had references to "fauxton@1.0.3 node_modules/fauxton" in the output. > > Does that answer the question? > > Aside, is what I did the best way to get a mostly-stable version of > fauxton? I assumed that would be more stable that pulling directly > from git. This goes back to my earlier question about releases; it's > not clear what the best way to get something new and usable is. > > Thanks, > Eli > > On Wed, Sep 16, 2015 at 3:06 PM, Michelle Phung wrote: >> Hi Eli, >> >> JIRA is the place for bugs. >> >> Its kind of tough to get people to look at it though, since there’s a lot >> going on with JIRA, and its a little endless. >> >> I thought we fixed the problem you described though. >> Did you pull from https://github.com/apache/couchdb-fauxton, the master >> branch? >> >> Michelle >> >> >> >>> On Sep 16, 2015, at 5:50 PM, Eli Stevens (Gmail) >>> wrote: >>> >>> Where is the appropriate place to file bugs against Fuaxton? Most >>> recent I see in JIRA is Feb. 15th of this year. >>> >>> As of a couple of hours ago when I updated my install, the view query >>> options UI wasn't respecting start and end keys (though the link to >>> the raw JSON is correct). >>> >>> On Wed, Aug 19, 2015 at 11:34 AM, Eli Stevens (Gmail) >>> wrote: I agree with kexpal's comment on the PR; large documents would make this very, very painful. I was asking for a view checkbox that would result in a 3rd column for view results (key / value / optional doc) that defaulted to off, so that I could include it when appropriate. Cheers, Eli On Wed, Aug 19, 2015 at 8:26 AM, Robert Kowalski wrote: > Thank you for your feedback! > > Based on the feedback we will try to enable `include_docs` per default: > > https://github.com/apache/couchdb-fauxton/pull/499 > > What do you think? > > On Wed, Aug 19, 2015 at 9:55 AM, James Dingwall > wrote: >> Eli Stevens (Gmail) wrote: >>> >>> On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall >>> wrote: I get the impression that more whizzy effects (fade in/out, sliding divs etc) have been added which don't play nicely with remote sessions with low bandwidth so a preference to use more basic transitions would be useful. >>> >>> +1 >>> >>> Note that it looks like the mailing list strips screenshots, so you >>> might need to host-and-link them. >> >> Thanks Eli, I didn't notice that when I received a copy of my post. I >> have placed my unchanged comments and screen shots in a github gist >> available from: >> >> https://gist.github.com/JKDingwall/6b2a6377d94a83ea5d63 >> >> >> James >> Zynstra is a private limited company registered in England and Wales >> (registered number 07864369). Our registered office and Headquarters are >> at >> The Innovation Centre, Broad Quay, Bath, BA1 1UD. This email, its >> contents >> and any attachments are confidential. If you have received this message >> in >> error please delete it from your system and advise the sender >> immediately. >>> >> >
Re: Project Fauxton Feedback
I just (mostly) followed the instructions at (except for the -g part, since I didn't want it global): https://www.npmjs.com/package/fauxton And ran the following: npm install fauxton cd node_modules/fauxton/node_modules/.bin/ ; ./grunt couchapp_deploy Which had references to "fauxton@1.0.3 node_modules/fauxton" in the output. Does that answer the question? Aside, is what I did the best way to get a mostly-stable version of fauxton? I assumed that would be more stable that pulling directly from git. This goes back to my earlier question about releases; it's not clear what the best way to get something new and usable is. Thanks, Eli On Wed, Sep 16, 2015 at 3:06 PM, Michelle Phung wrote: > Hi Eli, > > JIRA is the place for bugs. > > Its kind of tough to get people to look at it though, since there’s a lot > going on with JIRA, and its a little endless. > > I thought we fixed the problem you described though. > Did you pull from https://github.com/apache/couchdb-fauxton, the master > branch? > > Michelle > > > >> On Sep 16, 2015, at 5:50 PM, Eli Stevens (Gmail) >> wrote: >> >> Where is the appropriate place to file bugs against Fuaxton? Most >> recent I see in JIRA is Feb. 15th of this year. >> >> As of a couple of hours ago when I updated my install, the view query >> options UI wasn't respecting start and end keys (though the link to >> the raw JSON is correct). >> >> On Wed, Aug 19, 2015 at 11:34 AM, Eli Stevens (Gmail) >> wrote: >>> I agree with kexpal's comment on the PR; large documents would make >>> this very, very painful. >>> >>> I was asking for a view checkbox that would result in a 3rd column for >>> view results (key / value / optional doc) that defaulted to off, so >>> that I could include it when appropriate. >>> >>> Cheers, >>> Eli >>> >>> On Wed, Aug 19, 2015 at 8:26 AM, Robert Kowalski wrote: Thank you for your feedback! Based on the feedback we will try to enable `include_docs` per default: https://github.com/apache/couchdb-fauxton/pull/499 What do you think? On Wed, Aug 19, 2015 at 9:55 AM, James Dingwall wrote: > Eli Stevens (Gmail) wrote: >> >> On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall >> wrote: >>> >>> I get the impression that more whizzy effects (fade in/out, sliding divs >>> etc) have been added which don't play nicely with remote sessions with >>> low bandwidth so a preference to use more basic transitions would be >>> useful. >> >> +1 >> >> Note that it looks like the mailing list strips screenshots, so you >> might need to host-and-link them. > > Thanks Eli, I didn't notice that when I received a copy of my post. I > have placed my unchanged comments and screen shots in a github gist > available from: > > https://gist.github.com/JKDingwall/6b2a6377d94a83ea5d63 > > > James > Zynstra is a private limited company registered in England and Wales > (registered number 07864369). Our registered office and Headquarters are > at > The Innovation Centre, Broad Quay, Bath, BA1 1UD. This email, its contents > and any attachments are confidential. If you have received this message in > error please delete it from your system and advise the sender immediately. >> >
Re: Project Fauxton Feedback
Hi Eli, JIRA is the place for bugs. Its kind of tough to get people to look at it though, since there’s a lot going on with JIRA, and its a little endless. I thought we fixed the problem you described though. Did you pull from https://github.com/apache/couchdb-fauxton, the master branch? Michelle > On Sep 16, 2015, at 5:50 PM, Eli Stevens (Gmail) wrote: > > Where is the appropriate place to file bugs against Fuaxton? Most > recent I see in JIRA is Feb. 15th of this year. > > As of a couple of hours ago when I updated my install, the view query > options UI wasn't respecting start and end keys (though the link to > the raw JSON is correct). > > On Wed, Aug 19, 2015 at 11:34 AM, Eli Stevens (Gmail) > wrote: >> I agree with kexpal's comment on the PR; large documents would make >> this very, very painful. >> >> I was asking for a view checkbox that would result in a 3rd column for >> view results (key / value / optional doc) that defaulted to off, so >> that I could include it when appropriate. >> >> Cheers, >> Eli >> >> On Wed, Aug 19, 2015 at 8:26 AM, Robert Kowalski wrote: >>> Thank you for your feedback! >>> >>> Based on the feedback we will try to enable `include_docs` per default: >>> >>> https://github.com/apache/couchdb-fauxton/pull/499 >>> >>> What do you think? >>> >>> On Wed, Aug 19, 2015 at 9:55 AM, James Dingwall >>> wrote: Eli Stevens (Gmail) wrote: > > On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall > wrote: >> >> I get the impression that more whizzy effects (fade in/out, sliding divs >> etc) have been added which don't play nicely with remote sessions with >> low bandwidth so a preference to use more basic transitions would be >> useful. > > +1 > > Note that it looks like the mailing list strips screenshots, so you > might need to host-and-link them. Thanks Eli, I didn't notice that when I received a copy of my post. I have placed my unchanged comments and screen shots in a github gist available from: https://gist.github.com/JKDingwall/6b2a6377d94a83ea5d63 James Zynstra is a private limited company registered in England and Wales (registered number 07864369). Our registered office and Headquarters are at The Innovation Centre, Broad Quay, Bath, BA1 1UD. This email, its contents and any attachments are confidential. If you have received this message in error please delete it from your system and advise the sender immediately. >
Re: Project Fauxton Feedback
Where is the appropriate place to file bugs against Fuaxton? Most recent I see in JIRA is Feb. 15th of this year. As of a couple of hours ago when I updated my install, the view query options UI wasn't respecting start and end keys (though the link to the raw JSON is correct). On Wed, Aug 19, 2015 at 11:34 AM, Eli Stevens (Gmail) wrote: > I agree with kexpal's comment on the PR; large documents would make > this very, very painful. > > I was asking for a view checkbox that would result in a 3rd column for > view results (key / value / optional doc) that defaulted to off, so > that I could include it when appropriate. > > Cheers, > Eli > > On Wed, Aug 19, 2015 at 8:26 AM, Robert Kowalski wrote: >> Thank you for your feedback! >> >> Based on the feedback we will try to enable `include_docs` per default: >> >> https://github.com/apache/couchdb-fauxton/pull/499 >> >> What do you think? >> >> On Wed, Aug 19, 2015 at 9:55 AM, James Dingwall >> wrote: >>> Eli Stevens (Gmail) wrote: On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall wrote: > > I get the impression that more whizzy effects (fade in/out, sliding divs > etc) have been added which don't play nicely with remote sessions with > low bandwidth so a preference to use more basic transitions would be > useful. +1 Note that it looks like the mailing list strips screenshots, so you might need to host-and-link them. >>> >>> Thanks Eli, I didn't notice that when I received a copy of my post. I >>> have placed my unchanged comments and screen shots in a github gist >>> available from: >>> >>> https://gist.github.com/JKDingwall/6b2a6377d94a83ea5d63 >>> >>> >>> James >>> Zynstra is a private limited company registered in England and Wales >>> (registered number 07864369). Our registered office and Headquarters are at >>> The Innovation Centre, Broad Quay, Bath, BA1 1UD. This email, its contents >>> and any attachments are confidential. If you have received this message in >>> error please delete it from your system and advise the sender immediately.
Re: Project Fauxton Feedback
I agree with kexpal's comment on the PR; large documents would make this very, very painful. I was asking for a view checkbox that would result in a 3rd column for view results (key / value / optional doc) that defaulted to off, so that I could include it when appropriate. Cheers, Eli On Wed, Aug 19, 2015 at 8:26 AM, Robert Kowalski wrote: > Thank you for your feedback! > > Based on the feedback we will try to enable `include_docs` per default: > > https://github.com/apache/couchdb-fauxton/pull/499 > > What do you think? > > On Wed, Aug 19, 2015 at 9:55 AM, James Dingwall > wrote: >> Eli Stevens (Gmail) wrote: >>> >>> On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall >>> wrote: I get the impression that more whizzy effects (fade in/out, sliding divs etc) have been added which don't play nicely with remote sessions with low bandwidth so a preference to use more basic transitions would be useful. >>> >>> +1 >>> >>> Note that it looks like the mailing list strips screenshots, so you >>> might need to host-and-link them. >> >> Thanks Eli, I didn't notice that when I received a copy of my post. I >> have placed my unchanged comments and screen shots in a github gist >> available from: >> >> https://gist.github.com/JKDingwall/6b2a6377d94a83ea5d63 >> >> >> James >> Zynstra is a private limited company registered in England and Wales >> (registered number 07864369). Our registered office and Headquarters are at >> The Innovation Centre, Broad Quay, Bath, BA1 1UD. This email, its contents >> and any attachments are confidential. If you have received this message in >> error please delete it from your system and advise the sender immediately.
Re: Project Fauxton Feedback
Thank you for your feedback! Based on the feedback we will try to enable `include_docs` per default: https://github.com/apache/couchdb-fauxton/pull/499 What do you think? On Wed, Aug 19, 2015 at 9:55 AM, James Dingwall wrote: > Eli Stevens (Gmail) wrote: >> >> On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall >> wrote: >>> >>> I get the impression that more whizzy effects (fade in/out, sliding divs >>> etc) have been added which don't play nicely with remote sessions with >>> low bandwidth so a preference to use more basic transitions would be >>> useful. >> >> +1 >> >> Note that it looks like the mailing list strips screenshots, so you >> might need to host-and-link them. > > Thanks Eli, I didn't notice that when I received a copy of my post. I > have placed my unchanged comments and screen shots in a github gist > available from: > > https://gist.github.com/JKDingwall/6b2a6377d94a83ea5d63 > > > James > Zynstra is a private limited company registered in England and Wales > (registered number 07864369). Our registered office and Headquarters are at > The Innovation Centre, Broad Quay, Bath, BA1 1UD. This email, its contents > and any attachments are confidential. If you have received this message in > error please delete it from your system and advise the sender immediately.
Re: Project Fauxton Feedback
+1 ermouth 2015-08-18 21:03 GMT+03:00 Eli Stevens (Gmail) : > On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall > wrote: > > I get the impression that more whizzy effects (fade in/out, sliding divs > > etc) have been added which don't play nicely with remote sessions with > > low bandwidth so a preference to use more basic transitions would be > useful. > > +1 > > Note that it looks like the mailing list strips screenshots, so you > might need to host-and-link them. > > Cheers, > Eli >
Re: Project Fauxton Feedback
On Tue, Aug 18, 2015 at 1:11 AM, James Dingwall wrote: > I get the impression that more whizzy effects (fade in/out, sliding divs > etc) have been added which don't play nicely with remote sessions with > low bandwidth so a preference to use more basic transitions would be useful. +1 Note that it looks like the mailing list strips screenshots, so you might need to host-and-link them. Cheers, Eli
Re: Project Fauxton Feedback
> Where should I be listening to hear about when new > fauxton releases have happened? We don’t really do releases. We push to the repo, and then people can pull from there. https://github.com/apache/couchdb-fauxton Sometimes things break, but we try to fix them right away on the master branch, and new commits get merged in a few times each week. I think when 2.0 arrives, Fauxton will be the default UI. Wow. that just hit me that Futon will not be available with 2.0. . . . . . Michelle *scrambles back to work on Faxuton* > On Aug 17, 2015, at 6:10 PM, Eli Stevens (Gmail) wrote: > > Hi Michelle, > > Overall, sounds great. I'll reply inline where needed: > > On Mon, Aug 17, 2015 at 10:58 AM, Michelle Phung wrote: >> Feedback #2: Default _all_docs page doesn’t show enough relevant information >>Fair enough, this is something I think we should default with >> include_docs=true, but apparently it breaks some people’s browsers because >> the content of the data is extremely large. I’d like to revisit this idea >> though. > > IMHO it's less "not enough relevant info" and more "uses far too much > space for the information it does show." I think that directly cloning > the futon futon two-column view rendering is a good start, except: > > - Include quotes on keys (as talked about below) > - Pretty-print the value > > Note that I'm being explicit about showing the *value*; not the *doc* > when talking about include_docs=true. I could see having there be a > checkbox to add a 3rd column so that it renders key+id / value / doc, > but IMO it should default to off for the reasons you mention (having a > 4k doc repeated 20 times on the page would kinda suck). > > >> Feedback #3: Colors >>This is sensitive topic, and I learned this when I first started >> working in industry a few years ago: don’t question the colors. >>And then **definitely, without a doubt** do not use coding skills to >> change other peoples colors :) >> >>I’m glad you mentioned it so I didn’t have to. >> >>What I’m hearing is that you’d like the text colors to be consistent >> across the UI. >>And that it’s disorienting to switch background contexts that quickly. > > Yep, exactly. The hamburger being dark while the rest of the UI is > light is fine. > > >> Feedback #4: There's no obvious way to get to a nicely-rendered document >> overview. >>> — Could you expand on this? I’m not getting a clear idea of the problem — < >>Also RE: >> >>> I really want to click on the red ID 5d964eab30b5656190b416bff6210b69 >>> header part; >> >> >>You can double click on the document ‘card’, and it will take you to >> the full page editor! >>Not very intuitive, but once Kxepal told me it was possible, I love >> it, I do the double click all the time now :D >>FWIW, I would also like the ability to directly edit the document >> ‘card’, from the _all_docs page. >>I think that would be neat. > > The discoverability of the double-click handler is low. I don't know > how to learn that's the case without someone telling me. > > I'm asking for something like the futon doc editor, where it's > possible to edit the individual document fields one at a time, rather > than the whole doc. Having to do the whole doc at once is painful when > the doc is 4k lines long (see my earlier gist). > > >> Feedback #8: Query Options >>Interesting. I had not considered putting Query Options in the View >> Sidebar. >>I had a proposal to bring a duplicate button for include_docs=true >> option from the tray, and into the top of document cards area. Query Options >> can effect different types of calls, but it’s an interesting idea to have it >> built into the views sidebar. As I am thinking about this, I am liking the >> idea more and more. We could make a component out of it, and use it >> everywhere that needs query options. > > Nailing this could be a big enough deal-maker to override my earlier > deal-breakers. :) > > >> Cloudant has a new team of designers. They are new, and are just learning >> about CouchDB/Cloudant. We’ve asked them to take a look at CouchDB and how >> it could be better. They are interested in feedback, but for a different >> reason from what I’ve asked the mailing list for. I just wanted somethings >> to put into my presentation, but I am also very excited that I am getting >> this type of in-depth feedback! It’s really refreshing to hear. > > Glad my feedback is "refreshing" and not "pushy." I manage software > engineers for my day job, and it can be difficult to remove the > imperative tone sometimes. > > >> I hope I got everything. >> >> Thanks for your thoughts Eli :) > > Any time. :) Where should I be listening to hear about when new > fauxton releases have happened? I want to make sure I update my local > install promptly. > > Cheers, > Eli >
Re: Project Fauxton Feedback
Hi Michelle, Overall, sounds great. I'll reply inline where needed: On Mon, Aug 17, 2015 at 10:58 AM, Michelle Phung wrote: > Feedback #2: Default _all_docs page doesn’t show enough relevant information > Fair enough, this is something I think we should default with > include_docs=true, but apparently it breaks some people’s browsers because > the content of the data is extremely large. I’d like to revisit this idea > though. IMHO it's less "not enough relevant info" and more "uses far too much space for the information it does show." I think that directly cloning the futon futon two-column view rendering is a good start, except: - Include quotes on keys (as talked about below) - Pretty-print the value Note that I'm being explicit about showing the *value*; not the *doc* when talking about include_docs=true. I could see having there be a checkbox to add a 3rd column so that it renders key+id / value / doc, but IMO it should default to off for the reasons you mention (having a 4k doc repeated 20 times on the page would kinda suck). > Feedback #3: Colors > This is sensitive topic, and I learned this when I first started > working in industry a few years ago: don’t question the colors. > And then **definitely, without a doubt** do not use coding skills to > change other peoples colors :) > > I’m glad you mentioned it so I didn’t have to. > > What I’m hearing is that you’d like the text colors to be consistent > across the UI. > And that it’s disorienting to switch background contexts that quickly. Yep, exactly. The hamburger being dark while the rest of the UI is light is fine. > Feedback #4: There's no obvious way to get to a nicely-rendered document > overview. > > — Could you expand on this? I’m not getting a clear idea of the > problem — < > Also RE: > >>I really want to click on the red ID 5d964eab30b5656190b416bff6210b69 >> header part; > > > You can double click on the document ‘card’, and it will take you to > the full page editor! > Not very intuitive, but once Kxepal told me it was possible, I love > it, I do the double click all the time now :D > FWIW, I would also like the ability to directly edit the document > ‘card’, from the _all_docs page. > I think that would be neat. The discoverability of the double-click handler is low. I don't know how to learn that's the case without someone telling me. I'm asking for something like the futon doc editor, where it's possible to edit the individual document fields one at a time, rather than the whole doc. Having to do the whole doc at once is painful when the doc is 4k lines long (see my earlier gist). > Feedback #8: Query Options > Interesting. I had not considered putting Query Options in the View > Sidebar. > I had a proposal to bring a duplicate button for include_docs=true > option from the tray, and into the top of document cards area. Query Options > can effect different types of calls, but it’s an interesting idea to have it > built into the views sidebar. As I am thinking about this, I am liking the > idea more and more. We could make a component out of it, and use it > everywhere that needs query options. Nailing this could be a big enough deal-maker to override my earlier deal-breakers. :) > Cloudant has a new team of designers. They are new, and are just learning > about CouchDB/Cloudant. We’ve asked them to take a look at CouchDB and how it > could be better. They are interested in feedback, but for a different reason > from what I’ve asked the mailing list for. I just wanted somethings to put > into my presentation, but I am also very excited that I am getting this type > of in-depth feedback! It’s really refreshing to hear. Glad my feedback is "refreshing" and not "pushy." I manage software engineers for my day job, and it can be difficult to remove the imperative tone sometimes. > I hope I got everything. > > Thanks for your thoughts Eli :) Any time. :) Where should I be listening to hear about when new fauxton releases have happened? I want to make sure I update my local install promptly. Cheers, Eli
Re: Project Fauxton Feedback
Hi Eli! Thanks for your writeup! These feedback things are things we need to hear multiple times, to really drive the message home, so that we can be better, address real life problems, and also so that we can be held accountable for what we do. Let me know if I’ve misinterpreted any of the following: Feedback #1: Bring back tables (ok, we will do this :) I’ve heard enough voices to make it happen!) Feedback #2: Default _all_docs page doesn’t show enough relevant information Fair enough, this is something I think we should default with include_docs=true, but apparently it breaks some people’s browsers because the content of the data is extremely large. I’d like to revisit this idea though. Feedback #3: Colors This is sensitive topic, and I learned this when I first started working in industry a few years ago: don’t question the colors. And then **definitely, without a doubt** do not use coding skills to change other peoples colors :) I’m glad you mentioned it so I didn’t have to. What I’m hearing is that you’d like the text colors to be consistent across the UI. And that it’s disorienting to switch background contexts that quickly. Feedback #4: There's no obvious way to get to a nicely-rendered document overview. > — Could you expand on this? I’m not getting a clear idea of the problem — < Also RE: >I really want to click on the red ID 5d964eab30b5656190b416bff6210b69 > header part; You can double click on the document ‘card’, and it will take you to the full page editor! Not very intuitive, but once Kxepal told me it was possible, I love it, I do the double click all the time now :D FWIW, I would also like the ability to directly edit the document ‘card’, from the _all_docs page. I think that would be neat. Feedback #5: Keep JSON, as valid JSON, for c+p Feedback #6: too much whitespace :( we hear this all the time. I’ll bring it up to the designers. Feedback #7: Reverse-breadcrumb This is a good idea ! It would also clarify how closely CouchDB API works with Fauxton urls, and thus is another vehicle to teach people who are new to how CouchDB and REST APIs work. There used to be a UI for Cloudant that did this really well! Maybe we can convince people to bring it into Fauxton. Feedback #8: Query Options Interesting. I had not considered putting Query Options in the View Sidebar. I had a proposal to bring a duplicate button for include_docs=true option from the tray, and into the top of document cards area. Query Options can effect different types of calls, but it’s an interesting idea to have it built into the views sidebar. As I am thinking about this, I am liking the idea more and more. We could make a component out of it, and use it everywhere that needs query options. Feedback #9: Views editing and viewing page This needs work :/ Feedback #10: design/documents/views/etc needs better navigation This needs work :/ Now the big question: > What set of cases has the fauxton team been designing > towards? This is really a great question. :D :D :D For the most part**, me, Garren, Ben, Robert and me have been implementing new features, and taking care of the code base. We are in the midst of converting our code to use ReactJS instead of BackboneJS. So while we have a lot of coding help, we sometime neglect design, because we feel things must work first to be useful. **some notable people come and help us rebuild Fauxton as well, when they have time, and we are very grateful for their help ;) For me personally, I started working for Cloudant in September, and for a couple of months I was swimming in CouchDB vs Cloudant data, just trying to make sense of how everything worked. Then I tried to fix some JIRA tickets, and sneak in making the CSS better. Usually I am coding, although I wish I could spend much more time on the designing and information architecture mapping part. Cloudant has a new team of designers. They are new, and are just learning about CouchDB/Cloudant. We’ve asked them to take a look at CouchDB and how it could be better. They are interested in feedback, but for a different reason from what I’ve asked the mailing list for. I just wanted somethings to put into my presentation, but I am also very excited that I am getting this type of in-depth feedback! It’s really refreshing to hear. I usually go on IRC, and try to help out with questions that I can help with. This is where I get a sense of how people are using Fauxton, and what is confusing to them for CouchDB. Then I try to make it less confusing for them. Then I consult with the experts about why things are the way they are, and usually there is a reasonable explanation. Generally though we have a few goals we try to achieve: 1. Make it easy for a new couchDB person to get setup with
Re: Project Fauxton Feedback
Hi,
Thanks for asking for user feedback!
I just installed the default new(ish?) fauxton via npm, etc. from the
instructions at https://www.npmjs.com/package/fauxton (not sure if
that's as up to date as it could be). Here are my (hopefully
constructive) opinions. In general, I agree with a lot of James'
points, and it sounds like work is already underway to address the
biggest ones I have, but I'd like to add my vote to the record.
- The default view output is a downgrade from v1.6.1 futon, especially
when it comes to _all_docs. This one's a deal-breaker for me ATM.
Consider the following paste from the output:
ID 5d964eab30b5656190b416bff6210b69
{
"_id": "5d964eab30b5656190b416bff6210b69",
"_rev": "1-9462c2ccb60cb932e5003df4b148f712",
"value": {
"rev": "1-9462c2ccb60cb932e5003df4b148f712"
},
"key": "5d964eab30b5656190b416bff6210b69"
}
I'm shown the ID three times and the _rev twice, with no other useful
information. By separating the key+ID into the left column and the
value into the right, it's much, much easier to scan the keys to find
data I'm interested in. The syntax highlighting on the right in futon
makes it easier to visually parse the value. It would be nice if
fauxton pretty-printed the value, unlike the blob that futon has.
- The alternate choice of black-on-white and white-on-grey looks nice,
but isn't easy on the eyes, esp. when having to flick my eyes back and
forth between a dark sidebar, then a light sidebar and then the dark
data content. The database overview looks great; please use that color
scheme for the data content.
- There's no obvious way to get to a nicely-rendered document
overview. Having the futon two-column table with sorted top-level keys
on the left and values on the right is very useful. I'm not a huge fan
of how futon does editing from that document view, but it has definite
advantages when dealing with large documents. This one is also
probably a deal-breaker for me, but not as badly as the previous
point.
I really want to click on the red ID 5d964eab30b5656190b416bff6210b69
header part; it not going to that document is jarring.
- I like that fauxton doesn't hide the double-quotes on string keys;
being able to copy valid JSON directly out of the UI is nice.
- I agree with James that the default font size is too large, and
wouldn't mind slightly less margin/padding in general.
- I would highly recommend removing the "fixed" from:
table.table {
table-layout: fixed;
}
This results in a ton of wasted whitespace, and line-wrapping of DB
names since that column isn't wide enough (which results in yet more
wasted whitespace vertically). I have a high resolution screen for a
reason; let me use it! :)
- The page title should be a reverse-breadcrumb of doc_id < db_name;
or view_name < design_doc_id < db_name; etc.
For an example of the kind of data that I work with regularly, see the
lightly-anonymized json here:
https://gist.github.com/elistevens/a7d43fb306373f88644b
And an example view that has representative data for my typical use would be:
(doc) ->
for k,v in doc.state
emit [doc._id, k], v
My typical use case is "the UI doesn't look the way I expect; let me
drill down into the DB to see if the data powering that part looks
off." Being able to drill down into a specific sub-key quickly is
important. If it would be helpful, I'd be happy to pay attention to my
day-to-day usage of futon and report more accurate usage data.
- I'd like to be able to see and edit the query options I have in
place in full detail without having to click on "query options" and
scroll through a little text box. For example, I just entered this as
part of some real-world debugging I'm doing for my day job:
startkey:
["xyz_summary_2015-08-14_19.02.26.164089_9b11e5b33997ef5cc844b992b6e934a7",
"summaryRmsChart_data"]
endkey:
["xyz_summary_2015-08-14_19.02.26.164089_9b11e5b33997ef5cc844b992b6e934a7",
"summaryRmsChart_summary", {}]
Everything in the query options dropdown seems like it should all be
in the view sidebar, under the map and reduce sections (and tightened
up).
- The "Views are the primary tools for querying and reporting." text
can go away. 99% of users aren't going to need the tutorial once they
start using the UI for real.
- The views "Database" section duplicates the text two sections above
and can also go away. However, the title bar db name isn't clickable,
which is surprising.
- The "Design Document" and "Index name" sections look like they
should be navigational, but they're not. Having to go back out to all
docs to switch to another view (even in the same design doc) is
clunky. The futon dropdown was fast and straightforward here (though
I'd be fine losing futon's approach of having the built-in views
included as well). Having a separate "copy to new design doc and/or
view name" button at the bottom would retain the current
functionality.
On Fri, Aug 14, 2015 at 10:25 AM, Michelle Phung wrote:
> I didn't realize that Fauxton would be u
Re: Project Fauxton Feedback
Hi James, Thanks for responding! Its so interesting to learn about how people are using Fauxton! I've heard some similar concerns about the whitespace/font size issues. I'll raise it again with the designers that we are working with, so it's on their radar. I didn't realize that Fauxton would be used as a debugging tool! I feel really proud that it's useful in that arena. Regarding the layout breaking at smaller widths, this is also one of my pet peeves as well. I will also bring it up again to folks. I agree with you about the table structure (vs raw JSON preview). I am pushing that we definitely bring tables back (with an accompanying json toggle)! Your comment about most efficient the use of real estate is noted. I believe we could be doing something different as well. Some of the things I've heard (from you and others), is that the natural way people scan the screen for information is important, and we are not addressing that feedback (yet). :) Let me know what you think of the newest version if you get a chance to pull it. Thanks again, Michelle On Fri, Aug 14, 2015 at 1:07 PM, Michelle Phung wrote: > > > > Begin forwarded message: > > > > From: James Dingwall > > Subject: Re: Project Fauxton Feedback > > Date: August 14, 2015 at 11:26:04 AM EDT > > To: , > > Reply-To: u...@couchdb.apache.org > > > > Michelle Phung wrote: > > > > One of the things I would like to cover in my presentation is what > CouchDB > > as a community, would like to see implemented in Fauxton, and what can be > > improved. > > > > > > My experience of using the version of fauxton bundled in CouchDB 1.6.1 > (with SeaMonkey 2.33.1 in case its a browser thing...) > > > > Too much space around text in the layout , default font size too large - > I use the interface primarily as a debug/development tool so I want as much > in the browser window as possible and it doesn't need to look pretty. In > the futon interface I can see ~20 rows at a time against 7 in fauxton which > makes for a lot of scrolling. I do a reasonable amount of work in VMs and > have a limited screen resolution and even with a maximised browser window > the left hand menu generally overlaps the Database-Replication and > Documentation-Logout divs. If I adjust the view to 80% in the browser most > things layout better for my preferences. > > > > Once you enter the database another vertical column is rendered with the > design documents so between that and the fixed left menu half the page is > lost. I preferred the drop down selection of design documents/views in > futon due to its minimal use of page real estate but this feature was > slightly irritating in that it could take a long time to populate the drop > down over a slower connection. I am most interested in viewing/editing > documents so would like the design of the page to maximise the space > available for that function. There is no apparent option to increase the > number of documents shown in each page from 20 in fauxton. I also found > the two column presentation of view results in futon more easily navigated > than just presenting raw json. > > > > The default behaviour in fauxton is to show the expanded documents > instead of an _id which is a hyperlink to the document. When design > documents are a few 100kb this makes for an unresponsive browser experience > since these typically appear first in the all documents view. > > > > The edit document page shows the full json structure. When documents > are large this makes it more difficult to locate what you want to change. > In futon objects and arrays were shown collapsed by default but it was > still a bit awkward to edit deeply nested objects. Futon has separate edit > pages for working with the whole document or parts of the document. I > would like to see an edit mode where it is possible to expand objects and > then enable editing for only the expanded part of the object. In > particular this would be useful for large design documents which contain > many keys. I like the syntax colouring of fauxton in the whole document > edit page which helps to identify errors. > > > > James > > > > Zynstra is a private limited company registered in England and Wales > (registered number 07864369). Our registered office and Headquarters are at > The Innovation Centre, Broad Quay, Bath, BA1 1UD. This email, its contents > and any attachments are confidential. If you have received this message in > error please delete it from your system and advise the sender immediately. > >
Re: Project Fauxton Feedback
On Fri, Aug 14, 2015 at 6:39 PM, James Dingwall wrote: > Alexander Shorin wrote: >> >> On Fri, Aug 14, 2015 at 6:26 PM, James Dingwall >> wrote: >>> >>> My experience of using the version of fauxton bundled in CouchDB 1.6.1 >>> (with >>> SeaMonkey 2.33.1 in case its a browser thing...) >> >> You definitely should try the latest Fauxton[1] (better with 2.0[2]) >> because their codebase difference cover one year of hard work. Then >> you need to reconsider your experience with Fauxton (: >> >> [1]: https://www.npmjs.com/package/fauxton >> [2]: http://couchdb.apache.org/developer-preview/2.0/ > > > Can I point a newer fauxton at an older CouchDB? AFAIK yes. With npm package you just specify URL of your CouchDB. However, I don't guarantee that all the features will work there as it mostly oriented on 2.0 now. -- ,,,^..^,,,
Re: Project Fauxton Feedback
On Fri, Aug 14, 2015 at 6:26 PM, James Dingwall wrote: > My experience of using the version of fauxton bundled in CouchDB 1.6.1 (with > SeaMonkey 2.33.1 in case its a browser thing...) You definitely should try the latest Fauxton[1] (better with 2.0[2]) because their codebase difference cover one year of hard work. Then you need to reconsider your experience with Fauxton (: [1]: https://www.npmjs.com/package/fauxton [2]: http://couchdb.apache.org/developer-preview/2.0/ -- ,,,^..^,,,
Project Fauxton Feedback
Hello! I am at the beginning of writing a presentation that I am hoping to name: "The State of Fauxton 2015", and I would like to include community concerns about Project Fauxton, and where we hope it will go. One of the things I would like to cover in my presentation is what CouchDB as a community, would like to see implemented in Fauxton, and what can be improved. I would really appreciate some ideas if you have time. Thanks! Michelle Phung *General Person*
