couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michelle Phung <>
Subject Re: Project Fauxton Feedback
Date Mon, 17 Aug 2015 17:58:44 GMT
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
	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 databases and documents
2. Stick closely to the API
3. Give information

I hope I got everything. 

Thanks for your thoughts Eli :)

Feel free to email more, as you see them see more things, although no promises on *when* :(
But do not to worry….
we will be….
eventually consistent.

I’m pretty sure it doesn’t work this way, but:

ping @garrensmith

could you guys chime in when you have a moment, if i’ve missed anything or gotten something
wrong :)

> On Aug 15, 2015, at 12:28 AM, Eli Stevens (Gmail) <> wrote:
> Hi,
> Thanks for asking for user feedback!
> I just installed the default new(ish?) fauxton via npm, etc. from the
> instructions at (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:
> 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 used as a debugging tool!
> I was surprised to read this, since that's basically the only thing
> that I use futon for, and am having a hard time imagining other use
> cases (I think that this speaks to both the strength of CouchDB being
> able to address a wide array of uses, and to weaknesses in my
> imagination ;). What set of cases has the fauxton team been designing
> towards?
> Thanks for reading,
> Eli

View raw message