Planning for Wider Release

David Springer

Hello!

As I mentioned in this post, we've now released what I consider the critical pieces for Query to be broadly useful to customers at large. As such, I'm currently targeting a first limited availability wave next week. From there, we'll evaluate continued feedback and plan to transition into general availability by the end of the year.

We're still working on additional features, and will continue working on tweaks and feedback items like the ones you've been sharing here. As a reminder, here's the big stuff still coming:

• Query merges
• Ask fields
• Query search component (to include Query in web view features)
• Address Processing fields

THANK YOU for all the feedback you've provided up to now. It's been critical to get us where we are today. In the next couple days I'll send a survey to ensure we're also getting feedback from those who don't regularly check the Community.

The primary questions for the survey are:

• What, if anything, would prevent you from sharing web view query with other users?
• What, if anything, would prevent you from using web view query for the majority of your query work?

I'm specifically looking for any gaps outside those listed above, or DBV functions that you plug queries into, or when using a query to update fields that aren't yet supported in web view. (These are important, but already on my radar)

Feel free to respond here, email me at david.springer@blackbaud.com, or wait for the survey.

Again, thank you for all your feedback so far, and thanks in advance for your responses!

Maya Rosman 3

@David Springer - I'm responding to this thread so I'm sure it'll alert you (it won't let me tag you unless I'm responding to you). I'm trying to do task with a bunch of moving parts and I wanted to share with you a use case for why it's frustrating the way that webview query currently works. I'm cross-checking a query of my Active scholarships (using our system of constituent attributes that we use to track these) against my list of scholarships in BAM. I do this every year as I prepare for both our Spring scholarship solicitation period and our spring scholarship application round.

Because query opens in a modal and not in it's own separate window, it is much less customizable in sizing (and sometimes some columns cannot be made smaller than a certain point, which is frustrating) for when I need to look at the two sites side by side AND if I forget to open RE in a separate tab when I'm already inside the query cross-checking, it is very cumbersome for me to look anything up in webview. The types of things I'm looking up are: constituent attributes on constituent records (constituent search), fund attributes on fund records (navigating to funds in webview), looking up the latest gifts to a specific fund (a who separate query I need to pull up, edit, and run), fund relationships (not currently possible in webview). I am often doing all of these things all at once back and forth to double check that a scholarship is entered correctly and should/should not be solicited for in the current year. I also still cannot simply highlight the line of the query that I'm working on, because a single click brings up the modal for the constituent record, even when I do not want that - making it harder to find my place again if I get pulled away mid-task (this is why I talked about wanting a difference between single click to highlight a row and double click to open the record in earlier conversations). I do not see my need to work this way changing, so I'm hoping that something can be done to have query in webview better accommodate this type of work.

Essentially, doing these processes (which are essential regular processes) in webview is currently a lot more difficult, frustrating, and cumbersome than it was to do them in databse view. Query technically works, but webview query is making a lot of this work harder than it was before because of the UX.

I know there may not be much right now you can do to address these concerns, but I wanted to share/give feedback now that I am in the middle of a concrete task instead of just my memory of how this sort of task might work that I had when we spoke about these kinds of UX issues earlier in the EAP.

Maya Rosman 3

@David Springer
One more UX observation. I have a query where I've selected 73 of our funds (fund one of) in the criteria. Each year, I need to go into it and cross-check them against the funds that aren't selected and add some of those unselected funds to the query. In database view, this is very easy to do because selected and unselected funds show up in side-by-side windows. I've discovered today that in webview, it's a single list with your funds checked off, but worse is that it doesn't load the entire list. You have to keep clicking “load more” and I have several hundred funds so this is taking so much longer to accomplish in webview. If all I want to do is look at my 73 selected funds, I have to check the box for “show only selected items” but I STILL have to keep clicking “show more” and then it only shows me 2-4 more funds at a time. In fact, when I first got in there, I thought it was saying 73 funds, but only selected 1, because when I click on “show only selected items” only one fund is shown until I start clicking “show more”. It seems to have a built in number of funds it'll show at once, and it will only show however many funds are checked within that interval. This is much less than ideal. I often need to scroll through a list of RE fields selected in a query to check that I have what I need and if I have to take an extra 5+ minutes to keep clicking a button over and over, this is going to be such a time suck and will drive me crazy. Is there any way to add a way to “show all” instead of “show more” forever?

If you want to look at the query in question to see what I'm talking about, it's Scholarships with Pledges.

The type of task where I have a large group of selected system fields and need to either look at what I've chosen quickly or add to it is a pretty common query task for me, and the current UX is really terrible for accomplishing this kind of routine mainenance.

Maya Rosman 3

@David Springer
Follow up to the Funds one of list. The funds I need to select into this list are those funds that have a # in their fund code. In database view, I find them all by using a wildcard in the search field: *#.

I just tried that in webview, and it does not pull up any results. I tried without the *, assuming that the wildcard search is built it (i.e. it's a smarter search than database view) and still no results. This leads me to believe that in the Fund code selection area of query, wild card search is broken or not possible OR it is only searching the Fund Description and not the Fund ID. If I wanted to choose based on Fund Description, I'd have chosen that in my query. We have named all our endowed funds with a # at the end (so the spending fund would be FUND and the endowed fund linked to that spending fund would be FUND#). It has always helped us quickly identify these funds in the system. Right now, I cannot search for partial fund ID in query in webview and this means I cannot functionally update this query in webview.

Is this how it is supposed to work, or is the search not working properly in this case? If it's not working properly, can it be fixed?