In Qualtrics, is it possible to randomize the pages within a block? So for example, take this Block 1:
------Page Break------
1. Do you like cats?
2. Do you like dogs?
------Page Break------
3. Do you like parrots?
4. Do you like apples?
5. Do you like bananas?
------Page Break------
6. Do you like pizza?
7. Do you like fish?
------Page Break------
Is it possible randomize the order that each page appears (e.g., Q3,4,5 might appear first, Q1&2 second, and Q6&7 third).
I have a ton of survey pages, and it would be pretty painful to have to break them all up into many different blocks just to randomize them. (However, if there's an easy way to do that, I'd love to hear.)
Thanks for your help!
Edit: Even more complicated, what I also need to do is group pages together and then randomize based on groups of pages (e.g., Qs1-5 might be a group of pages, and would "travel" together during randomization).
This isn't possible, but you can shift click on the first and last question per page, click move and move all into a new block fairly quickly. That is the fastest way that I know of.
Related
I'm using Ascii doc to make rest documentation with Spring Restdocs. I have an overview section and then a section with operations. I want the operations to have numbered sections, but I don't want the overview and other sections to be included in the numbering. Also, I'd like to not have the "operations" header have a number, because that's the only section that's numbered, so it makes little sense.
So, what I have is something like this:
= Web service title header
[preface]
== Overview
overview text
=== Overview sub section 1
stuff
=== Overview sub section 2
more stuff
== Operations
:sectnums:
include::oauth2-scopes.adoc[]
include::oauth2-clients.adoc[]
And then controller-1.adoc looks like this:
=== OAuth2 Scopes
==== Get scope
operation::get-scope[]
==== Get all scopes
operation::get-all-scopes[]
When this is rendered, the structure itself is great, the sections inside of "operations" are numbered. But, the problem is that the numbers are weird.
It seems the "operation" header is forced to be numbered one, even though there's no number there and the subsequent numbers seem to know that the number is suppressed.
I hope that this is enough to go by. I'm not super experienced with Asciidoc, so I may be missing something.
I've thought of using a multilevel numbered list, but I want it rendered as headers with anchors, not just a regular list.
Edit: I'm working around it by putting the heading "Operations" and the same level as the included sections (level 2). This makes the TOC indentation off, but it's less distracting than the numbers being messed up.
Edit 2: I was wanting Operations to be at level two (==) and the name of the controller to be level three (===). I want the controllers to be numbered. It doesn't make much sense to have the section title be numbered 1 and then the things I actually want enumerated to be numbered 1.1.
I am not sure if I understand your question correctly.
If you need to optimise the weird numbering, make sure to reduce the level (from === to == etc.) This will fix that.
If you want to switch off the numbering at some point, set a ":sectnums!:" at the needed postition.
But if I am completely on the wrong track, please try to reformulate your question. And if you add a screenshot, please make sure it fits to your example ;-)
Struggling to find rank values from highest to lowest, please see attached example of what I'm trying to achieve.
My current custom expression is:
Sum([ViolationAmt])
I have tried this:
Sum([ViolationAmt]) over Rank([ViolationAmt])
I've played around with the rank expressions however unable to implement...would be very grateful for some help.
Spotfire Rank Example
I need to make a lot of assumptions here because I don't know anything about your data set or really what your end goal is, so please comment back and/or provide more info in your question if I am off base.
the first assumption is that each row in your dataset represents one, for simplicity, [AccountID] with a [ViolationAmt]. I'm also guessing you want to show the top N accounts with the highest violations in a table, since that's what you've shown here.
so it sounds like you are going to need two calculated columns: one for getting the total [ViolationAmt] per account, and then another to rank them.
for the first, create a column called [TotalViolationAmt] or somesuch and use:
Sum([ViolationAmt]) OVER ([AccountID])
for the second:
Rank([TotalViolationAmt])
it will be useful to read the documentation on ranking functions if you haven't already.
you could probably combine these two into a single column with something like:
Rank(Sum([ViolationAmt]) OVER ([AccountID]))
but I haven't tested this at all. again, if you put in a bit more detail about what you're trying to accomplish it will help you get a better, more detailed answer :)
Im trying to learn bourbon-neat, came across its breakpoint feature that takes a query and grid-columns. What is the use of grid-columns there? Why would you set the grid-columns like that when you can change the columns on the fly with declaration to span-columns?
Just need abit more explanation as to why you will provide a second parameter.
It is just to provide a little more flexibility. You may never use it, but for instance you may wish to have a 12 column grid for large screens and a 5 column grid for smaller columns. In this instance span-columns would not work as 12 cannot be divided by 5.
Admittedly you may not use it that often!
Here's what I'd like to do with Lift: I want to build a dynamic shopping cart, with lines able to be added and removed via AJAX calls. The total needs to be wired to the specific lines. Each line would include a number, the length of time for a lease, and a calculated price based on that, so I would have to add wired cells on each addable/removable line as well. So it would look something like this:
Number Length of Lease Price Remove?
(AJAX Textbox) (AJAX Dropdown Select) (Plain Updateable Text) (Ajax Checkbox)
(Another Row)...
+ Add
Total: ______
The problem I'm running into is that I can find resources to build a static page that displays all of this via Wiring. Using the Lift Demo site, I can pull up code that will let me add new lines, but it doesn't seem to me to be conducive to removing lines (this in general is one of my frustrations with Lift at the moment: a "little extra detail" to change from a tutorial ends up requiring me to completely change tacks and spend hours more at work and research, and I want to figure out how I'm probably approaching these problems wrongly!). Alternatively, I can use CSS selectors to dynamically create content, but I don't know how to effectively wire these together.
In addition, all of my attempts end up creating 2-3 times the amount of code I would have written to simply do some JQuery updates on the page, so I suspect that I'm doing something wrong and overcomplicating everything.
What resources would people recommend to set me on the right path?
These are your best resources for learning Lift:
Simply Lift
Lift Cookbook
Lift in Action
For any specific questions, I highly recommend you join us at the Lift Community Google Group. It is the official support channel for Lift. Although a few of us occasionally help out here at Stackoverflow, the best Lift help can be found there.
I've read somewhere (can't remember/find where) an article about web usability describing when to use drop downs and when to use autocomplete fields.
Basically, the article says that the human brain cannot store more then the last five options presented to choose.
For example, in a profile form, where there is your current occupation, and the system gives you a bunch of options, when you read the sixth options, your brain can't remember the first one anymore. This example is a great place to use an autocomplete field, where the user types something that he thinks that would be his occupation and then select the better from the few options filtered.
I would like to hear your opinion about this subject.
When should I use a drop-down and when I should use a Autocomplete field?
For a limited list, don't use an autocomplete edit box or combobox, but use a listbox where all values are visible all at once. For limited lists, especially with static content of up to about 8 items, this takes up real estate, but presents the user with a better immediate overview.
For less than 5 items a radiogroup or checkbox group (multiple selections) may also be better.
For lists whose content is dynamic, like a list of contacts, a (scrolling) listbox or combobox are appropriate because you never know how many items will be in the list. To keep it manageable, you will need to allow for some kind of filtering and/or autocomplete.
Autocomplete usually suffers from the fact that what the users types needs to match a string from the beginning. I hate those except for when they are used to complete a value based on what I typed in that (type of) field before. E.g. what browsers nowadays offer when filling out online forms.
Allowing a user to start typing in a combobox usually suffers the same drawback. But admittedly it doesn't need to if the filtering is based on "like %abc%" instead of "starts with abc"
When dealing with lists that can have many similar items, I really like the way GMail's "To" field handles it. You start typing any part of someone's name or e-mail address and GMail will drop down a list presenting all the contacts whose name or e-mail address contains the characters you have typed so far anywhere within them. Using the up and down keys changes the selection in the dropped down list (without affecting what you have typed) and pressing enter adds the currently selected item to the "To" field. By far the best user experience I have had so far when having to select something from a list.
Haven't found any components yet that can do this, but it's not too hard to "fake" by combining an edit box and a listbox that drops down when you start typing and has its contents is filtered based on what has been typed so far.
I would use 2 criteria,
1) How long is the list, if the list contains 5 elements you better use a combobox as it will be easier for the user (better UX)
2) In case the list is long, how easy for the user to remember the prefix of what he/she is looking for... if it's not easy, using autocomplete is irrelevant..
I'd say it depends on the diversity in the list, and the familiarity with the list items.
If for example the list contained over 5 car brands (list items I'm familiar with), no problem.
If on the other hand the list has over 5 last names, it could take me some more time before I'd make a selection.
You should probably just try out both options and trust your gut on which you find easier to use.
Here's the opposite approach:
The worst time to use an auto-complete box is when you have a finite and relatively small set of options, and the user doesn't know the range of valid options. For example, if you're selling used cars and you have a mixed bag of brands, simply listing the brands in a combobox is more efficient and easier to browse than an auto-complete method.
Being able to remember the last 5 options is most likely irrelevant unless you have a giant list of options and are requiring the user to select the most relevant item.
An alternative approach is to use both. I believe Dojo has a widget that acts as both a combobox and an auto-complete field. You can either choose to start typing and it will narrow down the possible options, or you can interact with it with your mouse and browse it like a combobox.
I usually look at how big the list is going to be. If there are going to be more than 15 options then it just seems easier to find if they can just start typing.
The other circumstance for me is when there is an other option and they can free type it. This essentially eliminates the need for two controls since you can combine in one.
The main difference has nothing to do with usability but more to do with what defines the acceptable inputs.
You normally use a ComboBox when you have a predefined list of acceptable inputs (e.g. an Enum or list of occupations).
An auto-complete field is best used when there are many known inputs BUT custom input is accepted as well. The user will become frustrated if they type "Programmer" in as their occupation but it wasn't one of the pre-defined, acceptable inputs, and they are given a message that their input is not valid.
Keep in mind that ComboBoxes do allow you to type in them to select the first matching option. Some types of ComboBoxes (depending on the UI framework you are using) even allow free-form text fields at the top or side of the field to search or add to the list.
Of coarse the best way to determine what YOUR user will prefer is testing: A/B, field, user, etc.
Hope this helps you solve your dilemma!