Graphical alternatives to mini-language to operate on large sets

Question

I am currently collaborating to a draft proposal for a new system where the main goal is to plan and then manage "assets" to satisfy "needs". An example (intentionally vague) - let's suppose you want to use this provide hotel rooms for people attending conferences and technical events - so you have a list of dates/places/expected attendances for the next year, and for each you have to contract rooms at hotels, based on various criteria including distance from the event location, price, transportation, catering, etc.

During the preliminary phase (let's say, 1 year before) you play with different scenarios, so after having created a "first draft" plan based on the actual conferences dates and attendance, you start fiddling with the numbers.

So for example

• "clone scenario 1 and create scenario 2" (this would just bulk copy everything)
• "increase expected room costs by 3% for all hotel space in Philadelphia from March 1st to April 15th"
• "split all hotel space in Detroit in Autumn - split moves 20% of spaces in a LUXURY allotment and increases cost for these by 15%, the remaining 80% stays at the same cost but is labelled as BUDGET"
• "For all LUXURY spaces in Detroit create requirements for Shuttle Services from Hotel to Location where the HTL-LOC distance is > .4 Km"
• "drop all LUXURY spaces in Detroit on September-15 along with linked services over "

Being a developer, I would find a sort of "mini-SQL" language more appropriate for this kind of operations (even if coupled with some graphical representation of the various allotments, always synched to the last executed command, so that the user can get a visual feedback of what is happening), but maybe I am just missing something due to ignorance/cognitive bias.

Is there some way to make this workable with a purely graphical interface (take in account that the number of "assets" in a specific scenario may be in the 3000-5000 range)?

Any specific site, application or book where I can find more about such an approach?

Additional note: I understand that users (even if in the specific case they would not be "infrequent users") might find a language cumbersome or not intuitive enough - what if we provided a sort of wizard to compose queries, bit like the one used in Outlook to define rules?

E.g. you first select the action from a drop down menu: Increase,Decrease,Delete,Split... etc. If you select Increase the wizard will ask you for which of the (numerical) values you want to alter (Price, number of rooms, number of beds...) then by how much, then over which period, which city and so on. Once the query is "completed" you could have a button to "simulate" the effect (so the sistem will tell you this will modify 63 records by just performing a count(*) using your parameters for the where clause and therefore the user can get an idea if this is roughly what he or she was expecting: if you get this will modify 78605 records you would realize that maybe city=all was not what you wanted) and when the user is satisfied another button allows the action to be performed for real.

Answer 1

Well in short - and I'm sure your team has come to this conclusion already - users won't be able to run all of these in one fell swoop. The closest you could get would be to mimic Excel-like functionality whereby users can add cell-level functions to manipulate the values.

My gut reaction/solution:

Grids. 3,000-5,000 records is a trivial amount. Minuscule compared to the number of assets and objects in most systems. Transactionally, concessions are required to make sure that things are captured by the database properly, but that's a concern for development and architecture.

Many banking apps nowadays will enable the user to perform bulk edits.

1. Select a bunch of transactions.
2. Set category to "Groceries".

Transactions, in this case, are your "asset", and will be displayed in some sort of a grid. Paginated or infinitely scrolled is another discussion, but a grid nonetheless.

The user has two options:

1. She can either scroll down the list, identifying each transaction she wishes to update, then take action (somehow).
2. Filter for the transactions she wants based on some criteria.

In your case, you have the criteria.

"Increase expected room costs by 3% for all hotel space in Philadelphia from March 1st to April 15th"

There's your filter. Assuming your grid has columns for Location and Booking Date, a quick filter on each column will expose the necessary rows you want to play with in your sandbox.

Back to banks. Like I said, many banking apps (think Mint, Simple, etc.) offer the ability to edit the metadata for multiple transactions at a time. In the image below, you can see that the user has filtered the transactions by searching for "Chipotle", and selected all entries.

On the right, a drawer is exposed showing each individual transaction, and there's an option to edit the data for all selected rows.

Clicking on Edit, the user is shown all editable metadata for the selected transactions. In this case: Name, Description, and Category.

I picture a similar approach for your situation. In the case of the aforementioned scenario whereby the user wants to increase all bookings by 3% during a given date range, we can simply add our operator to the bulk edit box for the associated piece of data.

"Booking Price" is merely a placeholder which represents all of the varied room costs for the selected transactions. As a user, I don't care what those amounts are...I just want to multiply them all by 3%.

---

For a split scenario, the user will proceed by filtering the grid as before, only this time will click a "Split" button. I picture this displaying a modal that asks the user how they want to split the rows (percentage, fixed values, random, etc.), then allows them to specify any bulk editing modifiers as before. Assuming the user can only split into two separate groups (irrespective of how big or small those groups are), your modal could literally be two columns side-by-side showing the following:

So they can set the percentages and apply the bulk changes at the same time. This would be very quick, and I think make a lot of sense to users. Certainly worth a guerilla test to two.

Answer 2

The requirements sound like a good fit for a spreadsheet-like application to me:

• the primary focus should be on the data - display as much info as possible about the records (5000 is not that many data, but you could use infinite scroll techniques)
• autofilter-like search on the data, saved searches and tick-box selection would provide the best way to select records for updating
• the most common actions could be accessible via context menu or icons or a ribbon
• "More" or "Advanced" actions from a drop-down menu
• if there were too many pre-existing possible actions, searchable combo box might be more appropriate than simple drop-down menu
• for Power Users, 1 of the advanced actions should be Custom Command which would open a text area - with on-the-fly syntax validation and ? icon to reveal a cheat sheet of available commands (ideally updated according to common support traffic questions)

Answer 3

This may not be an answer to the specific question you are asking ("Any specific site, application or book...?"), but perhaps it can help...

A drag-n-drop, graphical interface for Set-Manipulation should have a strong mapping of screen-geography to some aspect of the data being represented. When viewing a selection of Sets, the arrangement of those Sets on the screen should (in some way) represent the relationship between the Sets. Similarly, when viewing a selection of potential Set-Members, the arrangement of those Members on the screen should represent either their relationship to other members, or the values of one or more Member properties across the spectrum of possible property values. For example, convention attendees might cluster on the screen based on the companies they work for, or they may be spread across the screen in a 2-dimensional spectrum of attendee properties like "Job-Title by Experience-Level". The point is, neither the Sets nor the Set-Members should randomly spread across the screen; they should be arranged in a way that continually informs the user of the full range of available options.

Graphical interfaces often suffer from UX Noise, especially when the number of set members exceeds the available graphic representation. Thousands of members spread across hundreds of sets will quickly make your users wish for multiple 4K monitors so they can spread out and see it all. The obvious solutions for scale issues include grouping and zoom.

Grouping Allowing your users to aggregate individual set members into groups which themselves can be handled just like the set members. This will allow uses to cut down on the individual set member representations present on the screen at any given time.

Zooming Allowing your users to change the granularity of the interface can be thought of as "automatic grouping". "Zooming Out" pushes (screen-geographically) proximal items into temporary groups. "Zooming In" pulls members out of their temporary groups, returning them to their original screen location.

Getting Tired, so I'll describe my remaining thoughts a little more briefly...

Graphical Interfaces need to be extremely forgiving. Infinite-Undo is an absolute minimum. From the very beginning of the project, before the underlying data structure even starts to take form, you have to be thinking and designing for the undo feature. Your "Simulate" option is a start along that road, but the user shouldn't have to do anything special to make an action reversable. All actions should be reversable.

You should also consider making the Interface trainable. This is where your Mini-SQL or spreadsheet interface might come in. Allow the user to define an action that can apply to one or more sets. Allow them to tokenize any fixed values or percentages, such that they become questions to be answered by the user when the "macro" is run. Allow the user to save and later, edit any number of macros, gathering them into their personal (or publically shared) library.

The entire system should be extensible. Include a plug-in architecture (like Microsoft MEF) so that new verbs can be added to the macro language at a later time.

Answer 4

"Any specific site, application or book where I can find more about such an approach?" None I know of. Your best bet may be some Ph.D/M.Sc visualisation research thesis.

To get the UX design right need to understand the Users Domain and create a model of this in the system that they can interact with. What not many people realise is that SQL is a textual expression of set theory.

I remember seeing something with multi-dimensional axis and adjusting each axis independently to eliminate parts of overall sets. e.g. the aspects in example above would be

: Location : Date : Distance-from-Location : Percentage-of-Set-remaining : elements-not-in-set"X" (i.e. 'set complement' operation)

Place a sliders or controls (e.g. calendar with multi-select) that user can tweak settings for all of these. Just display the remaining area visually and count of elements 123/5000. Can display individual elements when numbers is < 10 or on user request.

Once set is selected the provide the operations:

1. Label and save the set [criteria]
2. Modify a property on the set - now or at a given date and time

These primitives should accomplish all examples given above, and quite efficiently

Also note in some cases with expert users, a text user interfaces have been tested to be as or more effective UX (e.g. operating system command line interfaces) than GUI's and should not discarded purely on principle or theory.

---

Edit added wireframe to help make a possible UI for this UX more concrete

^{download bmml source – Wireframes created with Balsamiq Mockups}

Answer 5

There are no magic pills in software design

It is easy to think in terms of functions tied to elements on a screen. This is prone to wrong impressions and a failed product. While a 'mini-language' might be one approach, there are probably dozens of other approaches that might work.

Software is only as effective as it's users and only as valuable as it's ability to meet business goals.

UXD is an iterative process of testing potential solutions with users to determine the best solution. Think in terms of prototyping and getting feedback. Then you will have the best choice of design/dev path.

My advice based on 12+ years of experience:

Prototyping is awesome - really. Do it as quick and cheep as possible.

• Prototyping Is Generative
• Prototyping — The Power of Show, Tell, and Experience
• Prototyping Reduces Misinterpretation
• Prototyping Saves Time, Effort, and Money
• Prototyping Reduces Waste
• Prototyping Provides Real-World Value

Observe the User Experience to see what people actually understand or get.

• In a cross-industry study of 630 U.S. and UK executives by the consulting firm Accenture, 57% of the executives reported that “inability to meet customer needs” had resulted in failures of new products or services.
• Fifty percent further blamed the “lack of a new or unique customer-perceived value proposition.”
• User research is the process of figuring out how people interpret and use products and services.

Apply Lean Principles to pragmatically uncover solutions.

1. Individuals and interactions over processes and tools. To generate the best solutions quickly, you must engage the entire team. Ideas must be exchanged freely and frequently. The constraints of current processes and production tools are eschewed in favor of conversation with colleagues.
2. Working software over comprehensive documentation. Every business problem has endless solutions, and each member of a team will have an opinion on which is best. The challenge is figuring out which solution is most viable. By building working software sooner, solutions can be assessed for market fit and viability.

A design solution is not a list of things to build. It is a process of asking the right design questions to get answers about what makes sense.

You may not be happy with this answer but there are no magic pills in software design.