I have a funny habit with our code in the front end, where if something’s just too complicated, but i cant see the better solution yet, I’ll give its pieces long descriptive names. It’s basically so they’ll stick out later, we’ll think ‘why is this thing so ugly and complicated’, and it’ll help us remember to revisit it. (btw, I’m not claiming that this is good development practice, it’s just a trick i use, faintly reminiscent of the blue-wire red-wire stuff in the Mythical Man Month).

So anyway, I bring it up cause Johnvey saw one of it’s cousins out in the wild, taking the whole concept to an extreme. Check it out.

Arguably though, this is so extreme that it’s not reallyDescriptiveNames at all, but closer kin to a sort of passiveAggressiveWorkplaceSabotageAdapter.

There’s lots of subtle things that are required for good user experience. Simplicity, speed, comprehensibility, consistency. These are the core value of any software, and there’s a spectrum on which they’re at the other end from ‘Features’.

Features are cool. They make you sound smart. Whether you’re a customer talking to a sales guy, or an engineer fleshing out an idea you had. New stuff tends to show up in sentences as the word ‘feature’. It’s exciting. Sure it has a certain cost in speed or something. It tends to not color entirely within the lines. But that’s OK. It’s new, therefore it’s cool.

Jumping forward many years though, everything at some point was new, and gets old and those costs start to suck. After a while these intangibles have pretty much been sacrificed away and you’re in large-company hell, sitting in endless meetings trying to figure out how and when everything got all bloated and slow.

So, we’re trying to swim against this current as we scale (no kidding). We’re trying to prioritize speed and simplicity. We’re trying to keep talking to users in the trenches. We’re fighting off checkbox-itis, we’re trying to have new corner-case features built in offshoot, quasi-standalone manners, we’re trying to use the extensible architectures we have, and create more of them when needed.

Im a pretty nostalgic guy, so hanging out with me there’s a lot of ‘back in the day’, ‘onion on my belt’ kind of stuff. You have been warned.

So my history at splunk — I started here in March ‘05. First UI Developer, inheriting the front end built by our notorious founder Erik Swan. They brought me in as a dHTML guru and gave me free reign (crossed fingers notwithstanding). But for better or for worse Splunk has always been pretty different on the client-side. Even the alphas and private betas all were all client-side XSLT and had that holy crap moment where you wonder why the hell everything is clickable and lighting up on mouseover.

Then during the sprint to 3.0 we ran off in even crazier directions, and did all the things we’d talked about doing, but held back from (eg endless pager, free form charting in Flash, rethinking the timeline interactions, replacing the tabs with more compact layers).

From this point forward though, there will be more building out and less building up if that makes sense. ie no more monolithic single all powerful UI, but rather links between quasi-standalone bits. And on the monolith instead of bolting on new features Instead we’ll be solidifying things, cleaning, improving, fixing.

iIf you only ever care about the last few hours or the last day of your data, this simple change will speed up your search results tremendously. Until our next big release which will basically be this way by default, here’s how you can do this in 2.1 code.

This is a change in three places, but fortunately very fast to make, and all in the same file.
$SPLUNK_HOME/share/splunk/search/dynamic/main_ui.html

Note: The example here will set your UI to search only the past 6 hours by default. After doing this it should be easy to see how to change it to search 1 day, or 45 minutes etc…

Note: Also you dont need to restart the front end to see these changes, but you DO have to refresh your browser by clicking the refresh button up top.

step 1) around line 70, change
<div class=”#productVersion#Version landingPageState #userType#User noTimeFields eventsTab relativeTimeMode #dynamicallySetStates#” id=”outerWrapper” />

to
<div class=”#productVersion#Version landingPageState #userType#User eventsTab relativeTimeMode #dynamicallySetStates#” id=”outerWrapper” />
(basically this removes the ‘noTimeFields’ state so the time controls are now open by default)

step 2) around line 122 of the same file, change
<input type=”text” id=”relStartTime” />

This is a quick update to Mark’s post from 10/9/2006

Again, to reiterate Mark’s qualifier - this is all assuming you understand that by doing this, you send users and passwords in clear text and the risks involved.

So, uncommenting the 2 lines as described in Mark’s post will only get you the first part, ie the ability to send a GET request that logs you in. We’ve had people ask if that request can go further and also return results right away for a particular search they also pass in. Obvious request but somehow we didnt anticipate it.

So until we wrap this feature up in a bow in a release, once again this involves editing python by hand. And this time it’s more than just uncommenting two lines. It’s cut and paste, and if you know python you know that tab-indentation is meaningful, and this seemingly simple action can be deadly. You have been warned. Back up the file and proceed carefully.

Alrighty, still with us? =) Find the 2 lines that Mark blogs about uncommenting. (this will be XMLResource.py, line 395 - 400 ish depending on which 2.1 release this is)

Everybody wants this, and until the day when it’s built into the UI somewhere, you can use this little bookmarklet to do it in about a minute.

So. the link below is your friend. (If you’ve used bookmarklets before you know what to do. Otherwise, read on. )

Instead of clicking this link though, right-click it or option click it, and choose ‘bookmark this link’.
splunk 30 second refresh

Once you’ve done that, then whenever you have Splunk loaded, clicking that bookmark will run the tiny little script, and the upshot is that the UI will start autorefreshing in 30 seconds and every 30 seconds thereafter.

And if you want to change the 30 seconds, edit the bookmark, find the 30000 and change it to whatever.

Full speed ahead for the next big round of improvements and fixes and we’re all going cheerfully bonkers. I was especially cheerful/bonkers today because I spent the morning prototyping some SVG stuff. In particular, since the splunk ui runs almost entirely on xml and client-side xslt, I was looking into how feasible/fast/stable it would be for our client-side XSL to just generate SVG directly, and for javascript to clone those svg nodes into a big complex DOM.

The answer is - omg it works well. Fast, seemingly stable, it can be pushed. Even in a big javascript front end like ours, the event handlers on svg elements pass right up into our existing framework. Some small tweaks had to be made to accomodate it, but no showstoppers. And it is rare for such a complicated thing to present so few obstacles in practice.
So thanks to Mozilla for being generally awesome, and particularly for turning on SVG in their release builds . Of course i have absolutely no idea if any svg will ever appear in the product … We do after all have a great deal of other more mundane improvements in the works. =)

First post, so i’ll begin at the beginning.

Im the front-end guy. From the xsl,js,html and css on the client side, up to the python in splunkSearch, I am responsible (read: to blame) for the current implementation, and also for much of the interaction design. I’ve worked here just over a year now, and I have no noticeable scars or weird tics to show for it, so I guess I’ve got that going for me.

What possessed me to come work here: Essentially all of my experience before splunk was at services companies, and for the prior 3 or 4 years specifically I had become this sort of high-throughput template builder and dhtml-specialist. Boring stuff I know, but I mention it because I came to splunk partly to get away from this. You can build lots of really complex front ends while at services companies. You can do build for flexibility and simplicity all you want, but when the project is over you never really see the code again (or worse the code never gets updated or changed by anyone and so it never evolves at all). So outside of maybe some escalated issues, you never really know what were the good parts of the implementation and what were the bad. And the development pain induced by changing requirements, the codebase evolution and accidental devolution, the day to day suffering really, you get spared from all that and that sucks.