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 <[email protected]> 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
