Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Feedback Requested

  Asked By: Rey    Date: Nov 15    Category: Sharepoint    Views: 918

I am new to this user group and I have recently
(within the last year) made the move to Microsoft Sharepoint from a
traditional web application development enviornment. I am not a
coder, I am a senior user interface expert, tasked with designing,
structuring, user friendly experiences within the Microsoft
enviornment. I am what you could call in line with Jakob Nielsen,
Cooper, Joel Spolsky, Bruce "Tog" Tognazzini, so I bring that
experience to the Sharepoint team at my company.

There are some things, detailed things, that I need feedback on to
better understand this enviornment. I work for Kaplan University, a
company of 4000+ employees with various departments and needs. We
Sharepoint Portal Server and Windows Sharepoint Services combined.
am trying to convey to my boss the best way to implement changes so
that we are efficient and still "user friendly".

One of the things I need to know in depth is the use of Dataviews
creating and developing Web Parts. Right now our home page is almost
ALL DONE in dataviews, and I find that rather cumbersome and
inefficient, since FrontPage is a nightmare to work with and seems
be the only tool that can effectively create "dataviews". However
since we're having to work on the live servers, having 4000+
and say half of them hitting the portal, it slows our process
Sometimes taking 10+ mins just to save an item.

My discussion points are these:

- What are the Pros and Cons of Dataviews?
- What are the Pros and Cons of Web Parts?
- Are there any other development tools besides FrontPage that could
be helpful for dataviews?
- What would you prefer to use, dataviewing or web part development?
- Has anyone created a mirrored "dev" server to work on and develop
in? If so, what were the basics of its setup?

Again, I am pretty new to this environment so forgive me if these
discussion topics are novice in nature.



2 Answers Found

Answer #1    Answered By: Jagdish Joshi     Answered On: Nov 15


In general, you want to use a List View Web Part (LVWP) if you can. This
is by far the most efficient way to show SharePoint data.

If you can't use a LVWP, use a Data View Web Part (DVWP) for displaying
data internal or external to SharePoint.

If you can't use a DVWP for displaying data (I'd like to understand  why)
then, and only then, incur the cost of using a custom Web Part.


Efficient use of the DVWP depends on several factors:

1. Be concerned (be very concerned) about the fact that your pages are
unghosted. This is a 15-20% performance hit not to mention the inability
to move  your solution to the next version of the product.

2. It is best to develop DVWP on your local environment and then deploy
them to your production server. It is not wise to edit them directly in

3. The XSL should be embedded in an external file not in the DVWP. You
do not want it embedded in the DVWP.

4. Caching (data and XSLT) can play a big role in DVWP performance. How
volatile is the data and where are your data sources located?

There is so much more I could say but it takes me about four hours to
say it in my developer class so I don't know how to do it justice in the

Ask a few more questions, answer the ones I've asked, and I'll try a
follow-up message.

Answer #2    Answered By: Shara Johnson     Answered On: Nov 15

small introduction about me will probably help you. I am not a
developer, firstly. I am an UI designer tasked with managing the look
and feel of 1) Sharepoint Portal Server and 2) Windows Sharepoint
Services team  Sites. Haven't yet touched on the TS stuff, we're just
working on the SPS atm. I am not very familiar with development  lingo
or the inner workings of Sharepoint. I am desperately trying to help my
new team get better organized.

I just signed on to my position here at an University as Senior User
Interface Designer and how they do things  here is completely with FP,
off the live production site too. Which to me is just completely
unacceptable. FP takes too LONG to load simple changes, when I open a
page in it, and change say for example width="200" to width="250" in the
code view of FP for example, it takes literally like 3 -4 mins to show
up on the design view, and locks up everything until its changed. THEN,
to save the page it takes another 5-7 mins just to save the page. Just
a horrible way to work! I find FP completely inefficient in the manner
that it's used here at work.

They have completely customized their Sharepoint Portal Server (cept for
top navigation), and its like 1001 data views all over the place.
Nothing is done in web  part development and we don't even have a
development environment to work  with. The home page of our portal site
doesn't list the team sites, a vital part of Sharepoint enviornment, and
its unghosted because they've done it all in FP and directly on
production (which is why it takes so long to do anything in it) and they
refuse to put lists directly on the portal home, they have it in other
areas further down the tree, which makes EVERY piece on the home page
forced into a dataview --- apparently this is due to the fact that they
wanted separate access levels for the lists that drive home page
content. They tell me there is no way to grant access to lists on the
home page without granting them access to completely change the home
page (Manage Content, Manage Portal Site, Edit Page, etc). I think
that's true for SPS, and not true for TS, unless we're wrong.

Our team has strong developers that as very smart with AS.NET and could
very easily create web parts for things that we need. Right now it seems
to me that we're creating data views of everything and then having to
RECREATE those same dataviews for other areas, where had we been using a
web part, we could easily re-use that functionality. Again, I am no
developer, but I believe that's simple common sense.

The one item that caught my attention the most of your feedback  below
was that we needed to be "careful of unghosted pages"... well over half
of the SPS pages we have are unghosted because of the over use of DVWP
and we have 3 Portals all with the same problems. Secondly, we do
EVERYTHING on Production because they believe we cannot set up a
traditonal "development" environment. And while I know that's true, at
Citrix we had an effective development environment set up where we would
replicate a mirror from production to a stage server (a "backwards
push"). We also mirrored it a development box. We'd work on stuff in
the Dev box, push it up to Stage for testing and then we'd deploy it to
production....which then we'd remirror the stage and dev boxes to start
on the next project. That is not the "BEST" environment, but its a
workable one imo.

I did not completely understand  how our XSL should be embedded in an
"external file" and maybe that's because I am not fully versed in the
development aspect of Sharepoint, I did however ask our developer and
they didn't know what was meant by that either. Our data is changed
2-3 times daily, its never static enough for us to work with without
having to set a "black out" from the content managers and stop all
editing, so that may answer your question as to how volatile our data
is? Maybe? I am also not sure where our data sources are located

Didn't find what you were looking for? Find more on Feedback Requested Or get search suggestion and latest updates.