tags:

views:

437

answers:

12

Are you the one that thinks: "Only if I had this thing available for me, I'll use SharePoint solution to solve my day-to-day problems?"

What do you miss in the SharePoint functionality that can make you happy?

What are the use cases that you think that SharePoint can solve for you but you miss something to make that happen?

Is it a web part? Component? Functionality? Integration option? Development complexity?

[I'll solve the most interesting ones and will make the solution available]


Summary

This is what we have so far:

  1. Complicated solution deployment
  2. Complicated development and testing (in connected or disconnected modes)
  3. Search is not working as desired
  4. Navigation is cumbersome
+5  A: 

Developing and testing SharePoint solutions using the API on a computer which does not have SharePoint installed.

Cory Foy
+6  A: 

Search.

Sorry for the rant, but...

Whenever I try to use Sharepoint's search functionality (as an end-user, I'm not a Sharepoint developer) it seems like I get the most retarded list of useless results. I either get nothing when I know for a fact there are documents that contain what I'm searching for, or I get a huge list of useless noise.


Then I get lost in a twisty maze of sites, collections, and lists; but I have no idea what the difference between all these things are and why sometimes when I'm in one I can't get directly back to another. Or something.

Makes me feel like a clueless idiot, which I suppose I am as far as Sharepoint goes.

Michael Burr
Well put. would have given +2 if I could :)
shoosh
Site Collection: The container for everything. No content (in Top Level Site). Top Level Site: The "root" site of a Site Collection. Subsite: Any site in a site collection that isn't a site collection itself. List: Well, a list of things http://www.mindsharpblogs.com/todd/archive/2005/12/22/923.aspx
Cory Foy
A: 
  • Storing a document to more than one document library
  • Enhanced version of content query web part that has the same functionality like a regular list web part (i.e. views, filters, sorting, easy to use interface)
Toni Frankola
+1  A: 

I agree with one other answer that it should be easier to develop in a non-server environment.

Also, it could do with better out-of-the-box support for accessibility standards.

BlackWasp
+2  A: 

Content deployment

It's been improved with all the releases Post-SP1 but you can't with ease deploy content in a Sharepoint. It's always risky.

There is a tool developed with Chris O'Brien called SPContentDeployment that use the content deployement API but it's still a 3rd party. It should be implemented within Sharepoint.

Pascal Paradis
A: 

ease of developing

well if they give more freedom for developer to be able to do what they need to do in the way they like to do it it will be great

the way it is now is just slowing my day to day work, still i have to work on it because bigger guys think it is the best thing out there

Ali
+2  A: 
  • Complete documentation, including the API, full documentation for CAML (not just the query language; any XML I type during the course of building a SharePoint solution should be considered a part of the API and documented), full documentation for the JavaScript library functions (e.g. ddwrt*), full documentation for the XSL bits, etc
  • Reliable API. This goes hand-in-hand with documentation; parts of the API don't have to be reliable so long as they're documented as such; e.g. if there are some activities that I shouldn't use in Visual Studio SP workflows, that's okay--just let me know which ones DO work. But things that should work all the time, like a spListItem.Update() call--these bits should work, so put some effort into squashing bugs.
Peter Seale
A: 

Having SharePoint optimized to handle huge document libraries would be nice. Somewhere on the order of 10 million plus would be nice. I know I am working with a pathological case, but performance drops off very rapidly when you get over 100k records in a library.

Jason Z
A: 

An aggregator that works accross site collections and web applications.

Running workflows at the list or site level instead of only at the item level. (would love this)

webwires
A: 

native silverlight webparts and better performance...

pabloide86
+1  A: 

I think SharePoint should be XHTML-Compliant out of the box. The fact that it isn't is quite laughable. Not to mention there's at least one control that outputs invalid HTML (missing close tag on SummaryLinks)!

A: 

My wishes to to Sharepoint [platform] do not differ with wishes to any other software products.

They should be clearly and easily predictable, explainable, supportable, manageable, able to integrate and solve the customers demands.

For example, Sharepoint is frequently explained, positioned, diluted, mixed and confused with by MS as portal solutions though such characteristic is not vendible because there are other (and more specific) MS products for these purpose but Sharepoint is rather better characterized as collaboration support platform.

It should be backward compatible and honest with customers.
How one should understand hardware requirements in "64-bit, four cores" for SharePoint Server 2010[1] if it really installs and runs without problems on computers with 32-bit 1-core processors?
What's the point in this cheating?

[1]
Hardware and software requirements (SharePoint Server 2010)
http://technet.microsoft.com/en-us/library/cc262485.aspx#section2

vgv8