One Search to Rule Them All — Why Google Cloud Search? (Cloud Next ’19)

Chad Johnson from SADA. I’m with Scott Lawson
from QAD, and we’re here to talk to you about
Cloud Search today SADA, for those of you that
are not familiar with us– we are full suite
Google Cloud provider. We were founded
in the year 2000, and we have been a multi-year
recipient of Partner of the Year from Google Cloud. As a matter of fact, we
were the global partner of the year for this year. Within SADA, I run
a practice that focuses on enterprise search. For about 10 years, I’ve been
working with Google’s Search Appliance if any of you are
familiar with the yellow Search Appliance that
Google used to sell. About two years ago, they
introduced Google Cloud Search, and it came out as
part of G Suite. It provides search across Google
Docs, Google Drive, Google Mail, Calendar, et cetera. And about two years
ago, we started working on a private
beta with Google to allow customers to index
non-Google content as well. So it was starting to fill
the space of true enterprise search. Within that practice,
I have consultants that do implementations. As a matter of fact, Scott
is one of our customers that I’ve been working
with for 14 years, I think. Scott and I have worked– I’ve been at three
different companies, and I’ve done work for QAD
and started with some content management projects and then
search, and now cloud search. Scott’s going to take us through
a little bit of a story that describes how their journey to
true total enterprise search has gone. It’s gone a little to
the left and a little to the right at times,
so Scott will take us through that story. SCOTT LAWSON: OK, thank you. Thank you, Chad. So I am– I’m going to go back here. So I’m the Director of
Enterprise Architecture at QAD. And I’ll tell you a
little bit about QAD, but we called our
session “one search to rule them all” based
on the Middle Earth legends of Tolkien, so you’ll
see some references to that as we go here. So QAD is a software
company for manufacturers. We make ERP, supply chain,
transportation logistics type software for manufacturers
in multiple verticals. So we’re a 40-year-old
company today– so a little bit
prior to the cloud. We were listed on NASDAQ
a little while later. We have a couple thousand
employees, a bunch of offices. We do seven complete solution
sets in six industries like automotive, medical,
consumer packaged goods, and so forth. And we have a lot of software. We can translate it
into a lot of languages. We have almost a half
a million customers or users in 100
different companies. And so we are complex. We’re confused. We have a lot of
stuff for a long time. And we’re also a
learning company, so we really want people
to be able to find all this information because, as
an information company, that’s what we sell. That’s our product–
our people, our factory. And we’ve been with
Google Cloud or G Suite, as it’s called today,
and with the GSA– the Google Search Appliance–
for about nine years or so. So this journey I want
to take you on through– our search– trying to find
one search to rule them all. So, that is, everybody
loves Google, right? It’s like, you
have a single box. You type something in. Boom– the results show up. You don’t have to worry
about going here and there and there and there
to find your stuff. You just go to Google. It’s a verb, right? We just to Google it. Well, for this journey with
Chad and now with SADA, we’re trying to get to that
place for our enterprise– for our enterprise content. So this is the history
of search at QAD. In the first scary dark
ages, we had systems– they have their own search, and
we search through the things. In 2002, we implemented
an enterprise system called Autonomy. It’s a search engine,
and it’s lovely. It was purpose built.
This is prior to Google. And we started to expand
Autonomy further and further through 2005. The problem with Autonomy
was it got really complex. It got really hard to deal with. It got really hard to pay
the bill for that thing. So then, in 2010,
Google came along with the beautiful yellow box. Who has a GSA in the audience? There are a couple of you and
that beautiful yellow box. It’s cool, right? I liked looking at
that in the data center among all those
black boring boxes. And we started to try
things out with Google. We did a beta kind of test
with the Drive Connector back in ’13, and Google did
a case study on us, so you can still
look that up today. But that was kind of a failure. It didn’t work. We didn’t use it after
all that because I think Google was
trying to figure out– they were like, OK, right,
we’re a cloud company. Why are we shipping
boxes to people? And so throughout ’13
to the further years, you can see the
expansion that we did. We added stuff to the GSA
like searching your drive, searching our internal and
external knowledge bases, searching video metadata
from Sonic Foundry Mediasite. We didn’t search the videos. We searched the content
around the videos so you could find a video. We added an employee directory. And I think, through there,
Chad was with us all along. CHAD JOHNSON: I think I
started with the Autonomy work actually. SCOTT LAWSON: Yeah, yeah. CHAD JOHNSON: Very
far back, yeah. SCOTT LAWSON: Yeah, you saw
this on that piece of junk, Autonomy, I think. CHAD JOHNSON: Yeah. SCOTT LAWSON: Was that right? OK, no, sorry, Autonomy. We love you. And we integrated,
then, in 2014, GSA deeper and deeper
into applications. So we started getting
more and more complex. And I have a few
slides to show you what that complexity looks like. But in 2016, we started
on signed on with Google as a trusted tester
for what would become Google Cloud Search. It used to be called the
Google Search for Work. And what did that do? That was a search box just
for Google content, right? So you could search Drive
and email and stuff. And that was great. That worked perfectly
out of the box. There was no box
because, basically, it was just a new app
that Google gave you or that you paid for with
your enterprise license. And in this last year, we
became a trusted tester for Cloud Search, trying
to look for that one search to rule them all– one search to find them is to
find all the content no matter if it was in Google or if it was
in our corporate repositories. So here’s a little
bit of a history here in what I call the olden
times, OK, in the ’90s. I don’t see anybody out there
that was alive in the ’90s, so you know, you’ve just got
to trust me on this one here. This was our box. This was our search
box on our website, and you can see
some features I have listed there like content
repository selection and so forth. My favorite is browser
copyright, right? 1996– Netscape
Communications– we actually have that on our main website. We moved a few years after
that into the Autonomy age, and you can see the
search box got better. It has more features. More features must
be better, right? So we have all these selections. We have multiple
languages, but we still had to have a user guide
on our site to tell you how to use the search. Have you ever seen a Google
search page user guide? Nope. So this was complicated, but
you could drill down into it. Fast forward a couple more
years into the Search Appliance, and you can see we now had
multiple repository selections. We have metadata displaying. We have filters and facets. And we have all kinds
of lovely stuff in here, and we have a source. I circled this over
here for videos. You could technically find
videos in this system. And then we had– the GSA used to have
this text rendering. So back in those
days, in the 2010, people didn’t really have
that great of internet. And so if you needed a 400
page PDF of a user guide, the GSA solution was to
give it to you in text so you could get
it when you were in a QAD office in
Thailand or South Africa or some other kind of place
without great internet. But that was the Google
Search Appliance, and it was really successful. CHAD JOHNSON: And,
Scott, at this point, what content sources
were you searching? SCOTT LAWSON: So in here, you
can see our content sources of videos from
Mediasite, learning from our learning management
system, knowledge-based forums, product updates, which
were a website we built, and product documentation,
which was yet another website we built. CHAD JOHNSON: And were you
on Google by this point, or getting close? SCOTT LAWSON: Yeah,
we went to Google in 2010, and throughout
that whole history– CHAD JOHNSON: But you couldn’t
see your Google stuff in here yet. SCOTT LAWSON: No,
no Google stuff. CHAD JOHNSON: Yeah, not
onto Google search box. SCOTT LAWSON: No, you had to
go into your email or whatever and search through that. So then, you’re right, I
won’t show a picture of that, but with the Cloud Search, you
could see your Google stuff. And we kind of
quasi-integrated them together. In this next screen,
you can see that this– we took a little
page from Google to make search look
a little better, and we added a layer on top
of it called the Twigkit. It’s a third party UI tool. And so what it shows
is facets and metadata and was able to embed the Google
Search Appliance results inside of our various applications. But this is confusing. Again, my journey here– the
reason I’m talking to you is because people
don’t really want that. We built that. People ask for that. They don’t really want 10
different places to go search. They want one search. And so what I’m going
to show you today is Google Cloud Search that is
searching both G Suite and QAD content. It’s appliance-free. I think it’s gluten-free
and sugar-free too. And it’s got a mobile app. You get it for free although
you can build custom UIs on it. We started to build our
custom UI at this point. We’re not quite
done, but I’m going to show it to you anyway because
I like to live on the edge. So we’ll have a live
demo a little later to show you what
this looks like. And on this page, this
is the mobile app. This is the web app. And you can see the results are
the same, and they go from– the top one is our own
repository– document library– sales resources–
our own repository. Here’s Google Groups, which we
use for forums and so forth. So everything’s all integrated
together for your term, and if you’re wondering
about this term, there’s an automotive
manufacturing term that’s super
geeky and boring, but I thought I’d show it. So I think I’m going to
continue here to tell you– OK, how did we get to this point
of what I’m going to show you? We have three business
considerations, and those three
considerations are mirrored by the
technical considerations that Chad will talk to you
about because there’s always two sides to it, right? You can’t just get Google Cloud
Search, and boom– you’re done. You have to think about things. So we’re going to look at what
to search, who can see it, and what does it look like. Content is what you’re
going to search, and I just listed
some types here that you need to think about. What do you have? You have articles and documents. What’s the difference between
an article and a document? Well, an article is like
a web-based web page kind of thing. It might scroll forever. You don’t really know how
big it is necessarily. A document is a PDF
file or a Word file or something like that. Videos, emails, all this kind
of normally non-searchable, private stuff that
you would think, well, we’re going to
separate that out. I’ll search for my
emails in Google– if you remember a few
weeks ago, Google’s Gmail became 15 years old, and
what was its premise? It was a search-based email. That was the whole premise. It didn’t even have any folders
on the side like Microsoft had. Of course, they succumbed
to pressure and put the folders in
there, but you have to think about email and code
and people and relationships because, when you search for
stuff, people make the stuff. Who made that thing? I want to find out who knows
about what I’m searching about, and maybe I can ask her a
deeper question about that. So content is one
of the main things that you need to think about. So after that, your
content has to be secured, and the security is complex. The security for
your search when you’re using Google Cloud
Search comes from the content. Google doesn’t know who
can see what inherently. You have to tell Google
who can see what. And so there are creators
of files and content. There are only viewers
of files and content. There are editors. You have to determine
what content is only for inside
people and only or also for outside people. There’s a middle ground, right? There are partners and vendors. They might be able
to see things. So for your business,
you have to think up what the rules are essentially. Also, PII– you
want to make sure that you’re not revealing
things so the GDPR police come after you. You have roles, reuse. You have to think about metadata
and how the metadata is going to tell Google Cloud
Search about your content, and then there are legal
ramifications of that. But of course, the end
user doesn’t really care about all that. The end user cares
about how does it look. And so these are
the glittering gems, if you read my description,
that the one search will allow you to find– my precious. Repositories are the vertical
silos that your content are in. You saw some of those, like the
knowledge base and the forums. You have to think
about your content and how it fits
into those buckets. How are you going to
sort it, filter it? What’s the meaning of
the words that come back? What is the age of the content? Are you going to do snippets or
not– those little bits of text that tell you what’s in that
link before you click on it? And I’ll be honest with you,
when you look at our snippets, you might snicker
at our snippets because they don’t
really make any sense. Some of our content that I’ll
show you are like PDF files– they have weird PDF file names. And it just comes
back from the name. So what is the title
of that document? How many results,
the pagination, and do you really need user help? Well, if you notice
in Cloud Search, if you’ve ever used– who’s used
Cloud Search on your content here? Wow, only one or two–
well, a few more. You’ll notice that there
is a little thing where you can click on a
button, and it’ll say “how do I use Cloud Search”
because you can phrase things like, “show me documents
shared with me” or “show me documents last
month” or something like that. And the hope– and I believe
what Google is going to do– is extend that kind of AI
smartness to your own content so that you can find those gems. So I’m going to pass
it back to Chad here who’s going to tell you
how technically to do that. CHAD JOHNSON: All right. SCOTT LAWSON: Want me to go? CHAD JOHNSON: Thanks, Scott. So this was the rejected
title for this session. I don’t know why Google
rejected it, but maybe for time. Just a little bit
more background on– because I want to open up
to questions at the end, so I just want you to
know that my background is in implementing these
enterprise search solutions. I’ve implemented hundreds of
them, and I know not all of you are familiar with Cloud
Search based on the hands. So I’ll give you just a little
bit of background on what Cloud Search is capable of. I’ll give you a little bit
of tips, tricks, pointers– just kind of key things
to think about when implementing Cloud Search. But then if you have
any other questions, please don’t hesitate. We’ll have a little
bit of time at the end. So I’m going to
follow the same three categories that Scott
covered, and this is how I scope projects. I think in terms of
these three pillars. I think in terms of what
content do I need to index, how does it need to be
secured, and what’s it going to look like
when we present it in the user interface? So the content
acquisition is difficult. There are a lot of
things to think about. There are a very wide
variety of content sources that people ask if
Cloud Search can search, and the answer is yes. But how? So we have to look at each
system on a case-by-case basis. We have to look at how
the application lets us retrieve the content. Let me kind of
elaborate on that point. So some people ask,
how does Cloud Search know about my content? So I’ve got a little
illustration here of where Cloud Search fits
in the architecture here. Cloud Search is not a content
management repository. It is not where the files
are stored, but it does have to receive a copy of
the files to index them. So if I’m indexing an
on-premise fileshare– in Scott’s case, we are
indexing on-premise databases– we write software that
will take that content– the metadata, the access
control information, the PDF, everything– and pushes it up
to Cloud Search. There is nothing in Cloud
Search that ever reaches back into your network, reaches
into your SaaS provider and pulls content. It’s deliberate. Anything that you want
indexed must be pushed up to Cloud Search, and you can do
that as frequently as you want. You can see that that’s
part of the challenge. How do I keep it fresh? How do I keep it current? I’m in Salesforce, and
I enter a new order, and then I forget where
I saved the order, and I want to search for it. Sometimes that happens
in 30 or 45 seconds. So sometimes we
have requirements that need to refresh the
content very, very quickly within a minute or two. It’s not that Cloud
Search has any restriction on how frequently
I can index it, but I’ll just leave
the point being that those traversal strategies
are where that sausage is made– how that’s done. One of our common
deliverables in projects are what we call connectors. Connectors are software that
can run either on premise or in a cloud environment–
anywhere that it has access to both ends. If you look at
the drawing, we’ve got several different types of
content sources described here. We have connectors that
can crawl web pages. We have connectors that
can select data out of a relational database. We have connectors
that can pull documents and structured records from
systems like ServiceNow, from Salesforce,
from Jive, et cetera. What they’re doing is
brokered by some software that Google developed called
the Cloud Search Software Development Kit. It’s a convenience layer. The Software Development
Kit makes it easier for you and I to
develop connectors. It makes it a little
more standardized, and it handles some of that
traversal strategy for us. It can handle
things like helping us detect the difference
between the things that I indexed yesterday. Maybe my system had 1,000
documents yesterday, and today it only
has 999, and I need to remove one from the index. So the Software
Development Kit has code that helps us
keep the index in sync and keep it fresh and current. In terms of the payload that we
actually send to Cloud Search– I mentioned that you do
have to send the document up to Cloud Search to be indexed– when Scott mentioned that we
have to deal with security, that’s part of the
payload as well. Every single document that
is sent to Cloud Search can include information
that describes who is allowed to see it. When you run a
search, you will not see things that you
are not allowed to see. You won’t get a link that
you try to click on the link and it doesn’t open– permission denied,
request access. But that means we have
to know those rules. We have to know who is
allowed to see everything. The other thing is
called metadata. It’s an overloaded term. It means a lot of
different things to a lot of different people. There is common metadata
that every system has. Those would be
things like the title of the document, the last
modified date, the URL– what to click on when I
see it in a search result. But Cloud Search also allows
us to load custom metadata, so if I’m loading
cases in Salesforce, those cases might
have categories. They might have departments. They might have which of Scott’s
products it’s related to. Scott showed– actually, I think
you will show in your demo, there’s facets along the
left-hand side that categorize the results– the content. Those come from metadata. So when I work with
you, and we talk about your vision for
your search results page, I have to know that you
expect to be able to filter the content by ticket priority. You’ve got P1, P2,
P3, and you want to be able to filter
and show only the P1s. That’s fabulous. I’m glad that you want
to filter by the P1s, but I need to know that metadata
about every piece of content that has a priority code. Cloud Search lets us design a
schema that the content will conform to. That means that I have to think
a little bit ahead of time about all those different
ways that I want to filter the content,
that I want to sort it, what I want to display on
the search results page. Scott will show the title of
the documents or the article. It will show that snippet
that he talked about, but it may also show
additional pieces of metadata. It helps you confirm
that a certain search result is the one
that you wanted or the one you were looking for. So we’re giving you context. We’re giving you
additional information. All of that comes back to
indexing and making sure that we push that
metadata into the index. So the second part
of this is security. You’ll notice there’s
a lot of overlap here. Security was
involved in indexing. I have to index the
security information. But there’s a lot more
going on with security. There’s identities. There’s usernames. There’s what group
am I a member of? Maybe I’ve restricted
content to anyone who’s part of a certain group. Oh wait, but we use
Active Directory, and that group information is
stored on premise or in ADFS. So how does Cloud Search
figure all this out? So, again, a small
illustration of what’s going on with identity
in Cloud Search– to set the premise,
I think we’ve already stated fairly clearly that Cloud
Search honors security insofar as we index the security and
support the identity management system. But it’s an intrinsic
part of the system. You cannot, at this time, run
an anonymous search in Cloud Search. It’s designed for things
where you are authenticated or you have a known user. I will say that, even
with Scott’s example, some of their search
goes to the public web. Some of their search is
exposed to anonymous visitors on the website. We can handle that. We’re currently doing it by
creating a web user in G Suite, and then Scott’s running their
queries under that web account. But it speaks to the inherent
security in Cloud Search. I had someone ask
earlier this week if there was a way to
turn off the security. Could I make it run faster
by not authenticating all of the queries? And yeah, the
short answer is no. It’s mandatory, and
it’s for a reason. It’s because it was built with
security in mind and security first. SCOTT LAWSON: But
that’s the way– I would have to say that’s
the way all services are going is that you log into
almost everything, and the power of that is that
it begins to know who you are. I mean, this is Google
we’re talking about, right? You know, the Eye of
Sauron looking at you and knowing what’s going on. CHAD JOHNSON: It’s not scary. It’s good. SCOTT LAWSON: I
love you, Google. But it really is a
good thing for users because, basically, if
you just Google your, you know, whatever,
it knows what restaurants you went
to and here and there, and that’s useful to you. So I think this is
sort of the new age. It’s the start of the
new age of the web– internally, externally
is going to know who you are and kind of give
you a much richer experience. CHAD JOHNSON: Absolutely. SCOTT LAWSON: So I
wouldn’t even want it turned off at this point
although, when we first started, that was
the question, right? CHAD JOHNSON: Yeah,
in that metadata, one of the things that
Google has that I haven’t seen any other service
providers offering is something called
interaction data. Interaction data is
a form of metadata that indicates users
that have recently accessed certain content. It keeps track of the files
that you’ve edited or viewed recently in things like Google
Drive with third-party systems. If we have access to that
stream of information, we can load interaction
data, and that will affect the ranking and relevance. I was giving a demo last year at
Next of the Cloud Search system and was expecting a certain
search result to come up in a certain spot,
and it turns out the previous time
that I did the demo, I ran the search and
then clicked on, maybe, result number five
or six in the list and was expecting it to
still be five or six, but a few minutes later
it actually jumped up to position two
because I had recently opened that document in
Drive, and it kind of caught me off guard. But once I realized
what was happening, it was actually pretty cool. So this is not something that’s
easy to do in a few minutes, but I’m going to use
this term “early binding” and just kind of briefly
explain what this means with respect to security. So we’ve set the premise
that Cloud Search needs to know who everyone
is that’s running searches. It needs to know who
can see each document. Scott uploads a document
into their portal. He says that this
can only be viewed by contractors and employees. It cannot be viewed
by guests on the web. He has set this access
control definition. Cloud Search works by knowing
all of that information ahead of time. If I have users that
are part of a group, and I’ve put
permissions on a file– maybe I have a group
called engineering, and you must be a member
of the engineering group to see a certain document. I have to make sure that the
document that’s in the index says that it can be viewed
by the engineering group. I have to tell Google that there
is a group called engineering, and I have to tell Google
who is in that group. Now, this gets more complicated
if I don’t use G Suite and I don’t use
Google Directory. So as part of our
projects, we go through a one-way
synchronization process, using something like Google
Cloud Directory Sync. Google Cloud
Directory Sync is used for a lot of different reasons– migrations, integrations
with G Suite. We often use it
when our customer wants to implement Cloud Search,
but he is not on G Suite. We can take their
users, their groups, their roles, their
directory information, put a shadow copy of that
in Google Cloud Identity, and then Cloud Search is happy. You can see this illustrated
over here in the diagram. We have our content
indexing that’s happening at the
top of the diagram. Underneath, I have this
additional synchronization that’s happening. I’m also pushing user
and group information, and I’m pushing
that ahead of time. That’s why we call
this early binding. There’s another form
called late binding, where it checks in real time
to see what groups you’re a member of and what documents
you have permission to view. Google found that those
systems tend to be much slower. They take longer to execute the
search because, at search time, it has to do a lot of
extra work to figure out what you’re allowed to see. With early binding, Google knows
immediately what you can see and what you can’t see. Search results are averaging
about half a second even with the round
trip to the cloud, so we’re getting extremely
fast performance even with secure search. The final section here– just
like Scott’s– was the user interface. So Cloud Search does come
with an “out of the box” user interface. Scott’s going to show
you both examples. He’s going to show you the
Cloud Search user interface that comes from Google. He’s also going to show you that
we can build custom interfaces, using what’s called
the query API. And there’s so many
more considerations when we start getting
into building custom UIs. Where do I deliver it? Do I embed it into my website? Do I create a standalone app? Do I put a search box in
the upper right-hand corner? Do I have facets down
the left-hand side? Do I let people sort or do
other sorts of filtering? What do I show? Do I just show the
title and the snippet, or do I show the title,
the year, the category, the department? Those types of clues
can help people feel more comfortable
with the search results. We build these applications
and can host them in a variety of
different places. So I’ve illustrated three
different scenarios here. I think it’s fairly
complete, but I’ll kind of focus on these three scenarios. One of the most common
scenarios that we have is that someone has an
existing application. That application needs
to show search results. That application is not
going to direct the user to interact with
Cloud Search directly. It’s all going to be brokered
through the application. This is very traditional
client-server that I’m describing. We’re talking about something
like a web application that has a search box. When the user types in
their query and hits Submit, it’s going back to
your application. And then the second box up
there is your application making the queries
to Cloud Search. This is great because you have
total control over the query. You can make sure that
the correct collection is being searched. You can make sure that
the correct filters are being applied. I was speaking to
someone yesterday who was not getting the
results that they expected with certain queries. They have the opportunity
in that service layer to adjust the user’s
query to make it better, to kind of help the user get
the results that they need. I won’t go into– there’s a lot of
different reasons why that might happen,
but just understand that you have complete and total
control over the queries that are sent to Cloud Search. The second option is
similar, but Cloud Search is an end user accessible API. It uses the OAuth2
protocol, and it means that you and I, if we are
logged into our Google account, we can query Cloud
Search directly. I don’t have to go
through your application. I don’t have to go
through a service layer. I can query, and I can hit the API directly. So Google created a very
thin, very fast JavaScript based UI called the
Enterprise Search Widget. It was designed to be embedded
into various scenarios but not deeply embedded. It’s not embedded
in the server side. It all happens in the browser. If you load this search widget
and watch your browser network connections, you’ll see
that the browser is actually formulating the search
query to Cloud Search, making the request, and
bringing back the response. It then renders the
response, and we can control the
rendering of that through the
JavaScript framework. The third option
is, because we can access Cloud Search
directly, we can embed this in other modalities. We can embed this in
mobile applications. Google has a Cloud
Search mobile application for iOS and Android,
and Scott is going to demonstrate
that everything that I have mentioned so far– the security, the connectors,
the integrations with on-premise and off-premise
content sources, all of this non-Google stuff,
even the customers that are not on G Suite– could use this UI if they
purchased Cloud Search and have a mobile ready application
without any custom development. So at this point, I’m going to
hand it back to Scott for demo. SCOTT LAWSON: All right, so
we’re going to go into the demo here, and this is the standard
UI of Google Cloud Search. And if you’re not
familiar with it, it first comes up
with your schedule. You can see this on my
calendar, and these are some documents I’ve looked at. So this is standard
Google stuff. And if I search for a term– and I’m going to
search for “kanban,” which is an automotive
manufacturing term– boom, I get search
results right away. But what you’ll not
see unless you’ve integrated Cloud Search
into your own repositories are these things. This thing here is
not in Google Drive. It is in what’s called
the document library, and I can click on that,
and it will bring up this PDF very quickly, OK? But here’s something in Google
Drive that I have access to. So all of these things
I have access to, and you can see you
can scroll down, and you can see
different types of things in this green lettering here. Now, you might say,
OK, that’s great. That’s like one page of stuff. But I can go and execute
this search on my email, OK? So here’s some email,
or I can go back to all. Or I can drop down
this more, and now I have these enterprise
repositories, these places that I want
to search, ready for me. So if I know I want to find
“kanban” on the support knowledge base, I
can see it over here, and Google currently
gives me some percentages of search results. So I can say, well, show me
kanban fixes or whatever, and when I click on
this particular element, it is now going off
to our knowledge base. This is a very
low-end knowledge base tool that absolutely
very few people use, but here it is, and it finds
that content quite efficiently. And I can see that this author
made this particular article, and I might say, you know what? I like this article. I want to talk to that person. Well, I can very easily
go back to Cloud Search. It brings up, because we’re
a Google customer on here– now, it’ll show me all of
the articles that he created, but I can go and say
“all” here, and then I can get more
goodness from Google. Here’s his phone number. Sorry about that, Nitin. Don’t call him. He’ll be mad at me. Here’s his Google Groups and
some other kind of information about that person. So that’s the regular
Cloud Search UI, and what I can show
you here is it’s the same when you’re on mobile. So over here is
my mobile device. And you can see I
have my various apps. These are my work
apps over here, and I click on the
Cloud Search button, and it shows me the same stuff. And in here, I can
execute the same term, and just like that, it shows
me the same results here. This is all live, running
from our standard setup. And I can move
across the top, and I can get those same
repositories over here and see what is
QAD forum for kanban, so here’s our forums over here. So that’s all in your pocket
ready to go anywhere you are. We absolutely did
not have that before. But if we want to go
and look at more detail, this is the custom UI. Now, I’ll apologize in advance. We’re still working on this UI,
and shoutout to my developers back at QAD for giving me
at least something to demo. And you can see I’ve
searched for nothing here, so it’s just showing
us a bunch of results. But I can search
for the same term, and it’s going to show me the
same results in a custom UI. But in this UI, if I drill
down into the support knowledge base, now I have all these
clickable facets down here to go and drill into, and I
can say, well, I want to see, in this catalog, what I
have for kanban over here in this catalog. And you can see the
facets change in here. So if I now go and
execute the same search– here’s the same person– I now have drilled down for
this term in my knowledge base on the subject of
Enterprise Edition– EE– by Nitin Joshi. So here is the same
results in here. Now, that’s kind of
geeky or whatever, but I can search for
stuff like Hangouts. QAD is– nope. Oh, yeah, because I
have to go over here– All. If I search for
Hangouts in All– come on, I forgot
to remove my facets. That’s something you
have to build in. So if I search
for Hangouts here, a common user might want
to do that and find out, not only stuff in Drive,
but we would find stuff in our knowledge base over
here as well as emails or on the web or whatever. So if I use a term,
such as automotive, I get all the results, but
I can drill down in here as Chad was talking
about, and these are results from our websites. And you can see the
different websites over here, and I can actually drill
down into our main website and get brochures in Chinese
and things like that. But I wanted to bring
this up because you see these ugly terms, right? These are PDF file
names that we haven’t sent over the appropriate data
to Google to make them pretty. And that’s what
we’re in right now. We’re in the middle
of that right now. So that’s really it on the demo. I just wanted to show
you where it’s at today. CHAD JOHNSON: One
of the differences– with, you sort
of expect the Googlebot finds what it finds. It’s just a head change to
think of enterprise search– you are in charge of everything. You’re in charge of the title. You’re in charge of the content. So there’s a lot of flexibility. You can send the wrong title. You could make up
your own titles. But to Scott’s point,
that’s just something we have to think
about, and we have to make sure that
everything is in sync and as we want it to
show up on the front end. SCOTT LAWSON: Exactly, so if
we can go back to the slides– CHAD JOHNSON: I
left it up there. SCOTT LAWSON: I’m sorry,
oh, you left it up here. We basically have–
these are our contacts. And you’ve heard
about us, and I think you want to announce
this guy in the middle. CHAD JOHNSON: Yeah,
so like I said, SADA– we are the North America Partner
of the Year for Google Cloud Search. Michael and I are definitively
the best in the business. I’ve been doing this
for, like I said, many, many years– hundreds
and hundreds of customers. Michael Orshan is my
counterpart from SADA. We work hand-in-hand. We work with some of the
largest companies in the world. If you have any questions
at all about Cloud Search– what it can do,
what it can’t do– if we could help you, please
do not hesitate to reach out. We would be honored to
work with you and help you. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *