Do like the new UI! :) Thanks for the update Russell & team!
A few notes and answers inline. On Jun 19, 2013, at 20:16 , Russell Branca <chewbra...@apache.org> wrote: > (Also gisted at https://gist.github.com/chewbranca/5816534) > > # Fauxton Tidings > > It's been some time since we've had a Fauxton update. There's been a > number of exciting updates with active tasks, replication, UI updates > and more. So let's dive in. > > ## Active Tasks > > Active tasks is an interesting item. Traditionally in Futon, active > tasks have been relegated to the status page, but I'm of the opinion > Fauxton should not only provide an interactive interface to your data, > but also a visual overview of the current pulse of your CouchDB > server. Things like active tasks, stats, and logs should be displayed > prominently in some sort of dashboard page. Garren has been working on > the logs and stats views in Fauxton, and DCH and Banjiewen have been > experimenting with new stats collectors. Long term I would love to > have a front dashboard showing you live views into this data. > > To start with, we're making active tasks a first class citizen of the > application. Any time you're in Fauxton, it will poll \_active\_tasks > and give you an immediate overview of the number of replications, > compactions, and indexing jobs currently running, giving you immediate > feedback on what is going on behind the scenes. Sue has been working > on an initial active tasks page that lists all the current tasks with > progress bars and ability to filter on the different types of tasks. I very much like the idea of a dashboard. Note that currently /_active_tasks requires admin creds, so there is an interesting user interface problem that needs solving if the first page one gets to requires that. I think this could be easily done by requiring a log-in for Futon proper, and changing CouchDB‘s setup procedure that the user/admin has to set a CouchDB Server Admin on first-start, something that makes sense for various other reasons as well. But there might be other solutions to this and I don’t want to prescribe anything here, I just wanted to point out that there is an interesting issue we need to consider :) > Long term I want to extend the active tasks page to do more advanced > visualizations and calculate rate of change to give estimates of time > to completion. What else would be useful here? How do you want to see > an overview of the background tasks running? I think we should formulate a few questions that the dashboard should answer by default. Something like: - how is my CouchDB doing? - if it isn’t doing well, what an I do? etc. > ## Replication > > In addition to active tasks, Sue has been working on a replication > interface. Step one is to build the transient replicator interface, > basically the same interface that is in Futon now, but with a proper > interface for all the different options such as choosing a filter > function, and specifying doc ids. > > Step two is build out a proper interface around the _replicator > database, allowing you to create new persistent replications, > introspect existing replications, look at historic replications, and > also to visually expose the powerful advanced options of the new > replicator allowing higher throughput replications. > > What kinds of interfaces sounds useful for interacting with the > replicator database? What would you find useful for creating and > managing replications through Fauxton? While a bit oblique in implementation, I like the git “remote” concept and I think it makes sense in the CouchDB context. Whether a remote is another CouchDB installation and databases are “branches” (in git lingo) or whether a database is a remote is up to decision, but I’d like to be able to configure a set of remotes for my current server (manually and automatically) and then start/stop/schedule/observe replication between the local couch and a “remote”, or two “remotes”, or whatever else makes sense. > One question I have, are transient replications through _replicate > deprecated in favor of interacting with the _replicator database? > at least as the default? Given that you can do one time replications > through the _replicator database, should we default to creating a doc > in _replicator rather than just POSTing to _replicate? We could always > have an option for both, but given that it will store stats and allow > you to see past history, it seems useful to use the _replicator db as > the default option. Thoughts? These interfaces really need to be consolidated, and maybe the “remotes” idea above gives us a way out. > ## UI Updates > > I'm excited to report that there are some great new designs for the > Fauxton UI. > > ### _all_dbs page > >  > > Notice in the left hand bar the "active tasks" this will live update > with the current number of tasks, and then allow you to go see a > detailed view. > > ### Documents and indexes overview > >  > > I'm a big fan of how this page turned out. The idea with the list of > items is that the darker grey area with \_id and \_rev are the primary > display of elements, and then you can toggle "collapse" above to show > the inner content, basically it's a display for ?include\_docs=true. > You can also keep it collapsed by default and click on the row to load > that doc and display it inline individually. > > Initially the display is more of a document oriented approach in that > it displays the json structure of the rows. The next step is to add a > tabular view of the data, which is particularly useful for displaying > views with complex array keys and scalar values. > > ### View editor > >  > > This is a fun page. The left hand editors for the map and reduce > queries both use the CodeMirror editor which does nice syntax > highlighting and proper indentation, and then we run every change made > through JSHint and do live error notifications, and provide inline > alerts right at the line in question. > > Also note the preview button. We borrowed the in browser map reduce > implementation from PouchDB and provide preview functionality by > running a subset of your documents through the map reduce functions > directly in the browser, allowing us to skip temporary views. Long > term it would be great to rebuild the temporary view system to only > operate on a subset of the data, but until then, I think this is a > better approach for allowing you to write and edit views on live data. > > Also having the advanced query options is something I've wanted in > Futon for quite some time. There's some room for making group_level > and the reduce toggle more accessible, but I think initially having > all the options available is a big win. > > ### Document editor > >  > > This is a slightly reworked version of the current code editor we have > now. Same as above with the view editors, this uses CodeMirror and has > all the nice live linting and what not. > > Not shown here is the work Garren has been doing on attachment > uploads, which are currently functional in master. > > There has been some discussion about removing the stand alone page for > the document editor and replacing it with a modal popup, so you can > click the edit button directly from the documents and views list and > have it show up immediately without losing your place. Thoughts? I see myself hating the modal, when I want to edit a bunch of docs in a row and try to open them separately “in a new tab”. We could come up with a bunch of user stories that describe common workflows and then build the UX design from there. In addition, this would give us high level testing scenarios that we could automate and make sure we wouldn’t break down the road. > ## Wrapping up > > Well my battery is about to die and this turned into quite the update. > Overall there are a number of exciting new things in Fauxton, and I'm > really stoked with how the UI design turned out, props go out to Sean > from Cloudant on that, my CSS is limited to adding Bootstrap elements. > > There's a lot of good activity going on in Fauxton, and it's quite > straightforward to get up and running now. We've also got a number of > open JIRA cases for anyone looking for something to work on. Cheers! Thanks again, great, great work! :) Jan --
