What Software Mockup Tool Do You Use?

It’s not often that we come across a tool that makes us go ‘WOW’. Balsamiq’s Mockups for Desktop flagship product did just that when I gave a demo of it yesterday to the internal team here at Black Ninja. I vaguely remember DHH tweeting about this tool and I made a mental note to take a look at it in more depth a bit later. Well, yesterday was that day for me and I have to say I am thoroughly impressed.

I was able to mockup a UI of a custom page I’m about to build in SharePoint and it took me a little over 1 hour to produce the png that I eventually sent to the client. As a pleasant side-effect, the client was quite impressed by my mockup. If you’re interested and want to learn more, check out their 3-minute demo video or their online examples, it’ll give you a good idea of how easy this tool is to use.

Here is my summary of this tool:

• Very easy to install, I was able to get it downloaded, installed and ready to use in about 2 minutes.
• Very easy to use, when you first install the app, the default page that loads is a UI mockup that gives you some guidance on how to use the tool. I thought that was very clever.
• I did not need to read a help file, access a kb or talk to a support person to start making mockups.
• I can save all mockups I create, and when I’m ready to present to my clients, I can save as png and email to them.
• My email inquiry was responded to in about 2 hours.

Why Should Indexing a SharePoint Field Break Your CAML Query?

We ran into an issue today – one of our calculations that rely heavily on CAML queries stopped working. The CAML query we use – which we haven’t changed in forever and which used to work – now returns 0 results when run.

This is what our original query looked like:

1
2
3
4
5

<Where>
<Eq>
<FieldRef Name='Project' LookupId='TRUE'/>
<Value Type='Lookup'>100</Value></Eq>
</Where>

It’s not a complicated query, and this used to work. Used to. But for some reason, it doesn’t anymore.

And for some reason, if we change the Value from Type=’Lookup’ to Type=’Integer’ it magically works again:

1
2
3
4
5

<Where>
<Eq>
<FieldRef Name='Project' LookupId='TRUE'/>
<Value Type='Integer'>100</Value></Eq>
</Where>

Why will using Type=’Lookup’ suddenly fail, and using Type=’Integer’ work? Does this mean we need to change all of our CAML queries that use Lookup?

What changed? No new service packs. No recent patches.

We tried to retrace our steps, in the hope that we don’t have to rewrite all of our CAML queries and retest all our application pages:
1. No change
2. No change
3. Ah, one minor change, but all we did was create an index in the Project field because we have over 2000 items in this list.

Indexing the column should help optimize retrieving records from this list. But could indexing the Project field be the culprit? This seems to be about the only change we did on this list.

But I think to myself, it should not be the culprit. Right?

I am a database person, and I create indexes here, there and everywhere whenever I need performance gains on some of my reports (ok, let me qualify that, I index where it makes sense. Of course if it is a purely reporting read only database, then I will index the heck out of it. OLTP databases are a different story). So for me, I don’t think it should affect the way we retrieve our records using our CAML query.

We needed to test if this was the case, so we did a quick experiment:
1. Created a custom list with a field that uses a regular lookup to another list
2. Used CAML with Type=Lookup ——-> Works
3. Indexed the column
4. Re-tried the CAML with Type=Lookup ——-> Does not work
5. Tried CAML with Type=Integer ——-> Works
6. Removed index from column
7. Re-tried the CAML with Type=Lookup ——-> Magically works again

So, why would (or should) the implementation of our CAML query change when we decide to index, or drop an index, from one of our SharePoint lists?

We tried to look for an explanation, but we haven’t found any official documentation, or any definitive rationale.

Again, maybe I just don’t understand, but in my database world, creating indexes, or dropping indexes from my tables does not break my SQL queries.

So why should indexing break a query in the SharePoint world?

Anyone from Microsoft SharePoint team care to explain? I’m sure we’re not the only ones interested to know the answer.